Wikimedia Apps/Team/iOS/Release process
Jump to navigation Jump to search
Before the release:
- 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.
- When these tickets are in QA, we know we’re ready to prep the release.
- 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.
- As a subtask, file the asset ticket for the PM.
- The PM works on these tasks during the beta.
- 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).
- 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.
- 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:
- Once all pre-release items are checked off on the release ticket, we’re ready to go.
- 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.
- Update the release ticket with the release version number.
- The PM tests the release candidate before it goes live.
- We check with the team before the actual release.
- Everything should be fine at this point, but just in case.
- Push the button.
- 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.
- Done… for now.
Preparing for next release:
- 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
- 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
- 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
- Provide contributors list
- Ensure licenses are updated
- Get release tag
- Confirm release candidate build number
- Verify regression testing with TSG
- Verify tweaks
- Do actual submission
- Do final install sanity check
- Press release button
- Update wikis