Wikimedia Apps/Team/iOS/Release process

Before the release:

1. As we get close to the release date, there should be few tickets left to Ready for Dev.
   • At this point, decide the final scope, i.e. what tickets are going to be done in the final version.
2. When these tickets are in QA, we know we’re ready to prep the release.
3. File the release ticket. (This is a template that lives on the backlog; it’s copied over to a ticket on the release board.)
   • Use the checklist for as we go through the process of closing the board.
   • All team members are subscribed so they know the current status of the release.
4. As a subtask, file the asset ticket for the PM.
   • The PM works on these tasks during the beta.
5. Release the beta.
   • This will take 24-48 hours - plan accordingly!
   • In TestFlight, go to the Wikipedia app and select the TestFlight tab.
   • Look for confirmed beta build number, click version number, under Group, click External Testers, then click until complete.
   • Approval notification email comes from Apple.
   • The beta build goes to external testers and usually runs over the weekend (as there are more users over weekend).
   • Send email to mobile-l to announce beta and give description of what’s in it.
   • If there are additional beta builds, once the build is available, just do the first two steps (don’t need to repeat anything else).
6. Have engineers fix issues from the beta.
   • Crash reports - look at crash reports from the beta and fix any crashes with clear solutions. If it's not possible to reproduce the crash directly or find a clear fix, make a judgement call based on how invasive the fix is and how prevalent the crash is.
   • Regressions - fix regressions in functionality, things that broke that worked in the last app store build. This is also a judgement call, but generally any regressions should be fixed.
7. As another subtask, file the pre-release testing ticket.
   • Once the build is selected, assign to QA for regression testing and smoke tests

Ready to release:

1. Once all pre-release items are checked off on the release ticket, we’re ready to go.
2. Submit the final build to Apple: provide the build number and any marketing materials.
   • It usually takes a few hours to a day for Apple to approve the release.
3. Update the release ticket with the release version number.
4. The PM tests the release candidate before it goes live.
5. We check with the team before the actual release.
   • Everything should be fine at this point, but just in case.
6. Release!
   • Push the button.
7. Update the release ticket: add release date, github tag and SHA (ask the engineers for this), update the wikis, make sure the PM notifies mobile-l.
8. Done… for now.

Preparing for next release:

1. Create new board by copying existing board.
   • Got to Projects
   • Create Project
     • Choose Release icon
     • Additional hashtags: optional alternative names, short names, etc
     • Add team members
   • On Project page, select Workboard
     • Import Columns
     • Pick previous board
2. Add new release tag to Phab herald.
   • File a task for Max B to update the herald; use the "Create update herald request" link in the Backlog sidebar.

________________________________________________________________________________________________________

List of tasks

PM

• Identify beta candidate beta build by number
• Email for mobile-l for beta
• Email for mobile-l when published to store
• Provide What’s New text
• Get screenshot updates
• Sign off on regression testing

Engineers

• Provide contributors list
• Ensure licenses are updated
• Get release tag
• Confirm release candidate build number

Program Manager

• Verify regression testing with TSG

• Verify tweaks
• Do actual submission
• Do final install sanity check
• Press release button
• Update wikis