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.
 * 2) * At this point, decide the final scope, i.e. what tickets are going to be done in the final version.
 * 3) When these tickets are in QA, we know we’re ready to prep the release.
 * 4) File the release ticket. (This is a template that lives on the backlog; it’s copied over to a ticket on the release board.)
 * 5) * Use the checklist for as we go through the process of closing the board.
 * 6) * All team members are subscribed so they know the current status of the release.
 * 7) As a subtask, file the asset ticket for the PM.
 * 8) * The PM works on these tasks during the beta.
 * 9) Release the beta.
 * 10) * This will take 24-48 hours - plan accordingly!
 * 11) * In TestFlight, go to the Wikipedia app and select the TestFlight tab.
 * 12) * Look for confirmed beta build number, click version number, under Group, click External Testers, then click until complete.
 * 13) * Approval notification email comes from Apple.
 * 14) * The beta build goes to external testers and usually runs over the weekend (as there are more users over weekend).
 * 15) * Send email to mobile-l to announce beta and give description of what’s in it.
 * 16) * If there are additional beta builds, once the build is available, just do the first two steps (don’t need to repeat anything else).
 * 17) Have engineers fix issues from the beta.
 * 18) *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.
 * 19) *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.
 * 20) As another subtask, file the pre-release testing ticket.
 * 21) * 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.
 * 3) * It usually takes a few hours to a day for Apple to approve the release.
 * 4) Update the release ticket with the release version number.
 * 5) The PM tests the release candidate before it goes live.
 * 6) We check with the team before the actual release.
 * 7) * Everything should be fine at this point, but just in case.
 * 8) Release!
 * 9) * Push the button.
 * 10) 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.
 * 11) Done… for now.

Preparing for next release:

 * 1) Create new board by copying existing board.
 * 2) * Got to Projects
 * 3) * Create Project
 * 4) ** Choose Release icon
 * 5) ** Additional hashtags: optional alternative names, short names, etc
 * 6) ** Add team members
 * 7) * On Project page, select Workboard
 * 8) ** Import Columns
 * 9) ** Pick previous board
 * 10) Add new release tag to Phab herald.
 * 11) * 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