Mobile App Release Process
The Mattermost Mobile Apps team works on a monthly release process, with a new version submitted to the iOS App Store and Google Play Store on the 16th of each month.
Note: iOS App Store approval may take a few days after the 16th.
Notes:
All cut-off dates are based on 10am (San Francisco Time) on the day stated.
T-minus counts are measured in "working days" (weekdays, Monday through Friday, excluding the listed statutory holidays) prior to release day.
No pull requests for major features should be merged to the current release after this date. In special cases, exceptions can be made by the Release Manager.
Release Manager:
Post this checklist in Release Checklist channel
Draft Changelog in a WIP PR with updates for highlights, feature additions and bug fixes
Start posting a daily Zero Bug Balance query (posted until zero bugs or day of release)
PM:
Prioritize reviewing major features, ensuring any bugs and UX issues get fixed
Dev:
Prioritize reviewing, updating, and merging of pull requests for current release until there are no more tickets in the pull request queue marked for the current release
After the cut-off, any PRs that include significant code changes, require approval of the Release Manager and React Native PM before merging
Build:
Cut a beta build
Marketing:
Prepare a list of highlights to be included in the next Mattermost release announcement
QA:
Prioritize testing merged PRs and resolved tickets
Write and update tests in the Release Testing spreadsheet
Day when PM decides which major features are included in the release, and which are postponed.
(Team) Triage Meeting:
Begin daily triage of tickets
Release Manager:
Post this checklist in Release Checklist channel
Verify all items in the last posted release checklist are complete
Update Changelog PR based on what's in/out of the release
Post a link to Native Mobile Apps channel for query of remaining bugs in this release
PM:
Review the Jira tickets remaining in the current release fix version and push those that won't make it to the next fix version
Stabilization period begins when all features for release have been committed. During this period, only bugs can be committed to the release branch. Non-bug pull requests are tagged for next version. Exceptions can be made by the Release Manager during triage.
Release Manager:
Post this checklist in Release Checklist channel
Verify all items in the last posted release checklist are complete
Dev:
Prioritize reviewing, updating, and merging of pull requests for current release until there are no more tickets in the pull request queue marked for the current release
Check the minimum server version required and submit pull request to update in fastlane files
Build:
Create release branch for mattermost-mobile and mattermost-redux
Cut release candidate build
QA:
Confirm all pull requests merged into the current release have been tested
Ensure the release testing spreadsheet covers any changes and new features, and confirm known issues are listed in the relevant tests
Assign each area of the spreadsheet to a team member and give the core team access permissions
Docs:
Submit any remaining documentation PRs for product updates in the release
Release Manager:
Post this checklist in Release Checklist channel
Verify all items in the last posted release checklist are complete
Post list of tickets to be fixed to the Native Mobile Apps channel
Update Changelog for any new bug fixes
QA:
Post release testing instructions and spreadsheet to Release Discussion channel
As bug fixes are merged, verify fixes on new builds and post in Native Mobile Apps channel after testing
Team:
Test assigned areas of the testing spreadsheet and file any bugs found in Jira
Daily triage of hotfix candidates and decide on whether and when to cut next RC or final
Dev:
Make pull requests for hotfixes to the release branch
Review PRs made to release branch and merge changes into the release branch
Build:
Verify with Release Manager before cutting any new RCs (approved fixes should be merged)
Push next RC to acceptance and announce in Native Mobile Apps channel
PM:
Check that the release candidate is available to beta testers
QA:
Test the new RC to verify fixes merged to the release branch work
The final release is cut. If an urgent and important issue needs to be addressed between major releases, a bug fix release (e.g., 1.1.1) may be created.
Release Manager:
Post this checklist in Release Checklist channel
Verify all items in the last posted release checklist are complete
Submit Changelog PR for review
Merge Changelog PR after review is complete
Build:
Tags the release and cuts the final build
Upload the
.ipaand.apkfiles to GitHub
Marketing:
Finish draft of marketing images and send to marketing lead for review
Docs:
Finalize docs
If reviews are not complete, hold a 30-minute doc review meeting with PMs and anyone else who has changed or reviewed docs this release and wants to join
Submit a correction PR for any incorrect formatting or other errors missed during the initial review
Release Manager:
Post this checklist in Release Checklist channel
Verify all items in the last posted release checklist are complete
Schedule a release retrospective meeting, to be held within five days from the release
Post key dates for the next release in the header of the Native Mobile Apps channel and remove links to RC candidates and testing spreadsheet
Make sure that statutory holidays for Canada and US are accounted for in the release dates
Check for any UserVoice feature suggestions that were completed in the current release
Build:
Merge the release branch back in to master
Review and update project dependencies as needed
Submit final build to Google Play Store and iTunes Connect
Confirm that minimum server version required is clear in update notes
Create release in GitHub
Close the release in Jira
Marketing:
After the apps are approved and on the App Store (number of days may vary), send out release marketing
Update the app version on the download page​
Send out a Twitter announcement