Wikimedia Apps/Team/Android/AndroidReleasePhases

Development Timeline
At any given time, however, two releases are underway. The timeline, considering multiple releases.

Releases are tagged in the `main` branch. If any QA fixit PRs are needed, we'll branch off that tagged commit to create a release branch. The fixit PR will be merged into the release branch, a new build will be made from the release branch, and that release branch will be merged back into `main`.

Release engineer duties
With the frequent release cycle, one (rotating) engineer is assigned the release duties for the final two weeks of a release cycle. During that time, the following release's development work is being completed - so tasking one engineer with release considerations frees all other engineers to focus on development for the following the release.


 * Week 3, first thing Monday morning: Tag release branch. Build beta, but do not release it.
 * Week 3, Thursday: Ensure QA/signoff tickets are complete. If so, release beta build. ("Did not pass QA", "Design signoff", "QA signoff", and "Ready for PM signoff" should all be clear of tickets.)
 * Week 3, Thursday through following Wednesday: Monitor beta feedback/bugs, give updates to entire team.
 * Week 4, Wednesday: Confirm regression testing completed, and it passed. Release app to production on 3 app stores.
 * Week 4, Wednesday: Move items on Phabricator board - Archive tickets in "ready for release" column. Move the following release's tickets from "Merged and Waiting" to "QA Signoff".
 * Week 4, Wednesday through Friday: Monitor production bugs, give updates to entire team.

Android team development cycle
The following is an outline of the team's standard process. It is important to ensure that everyone has a shared understanding of what each phase means. There are no pre-set dates or durations for phases, as the team will discuss timing as they work and agree together on when to move from one phase to the next.


 * 1) Initialisation
 * 2) * Discuss concept with PM/engineers/UX research/analytics/RI and other teams to be informed
 * 3) * Prepare rough concepts/wireframes as needed to aid discussion
 * 4) * PM/analytics/UX research agree initial set of research questions (qual and quant)
 * 5) Research
 * 6) * Present design proposal to engineers/design research/analytics for feedback
 * 7) * Engineers begin technical discussions
 * 8) * Write placeholder Epics
 * 9) * Create prototype for user testing (preferably using InVision or similar)
 * 10) * Initial evaluative user testing
 * 11) Specification
 * 12) * Engineers agree on technical implementation details (and create mock APIs, etc)
 * 13) * Finalised designs and user flows completed and available in Zeplin (feedback to design as needed from engineers)
 * 14) * Analytics specifies tagging scheme based on research questions
 * 15) * Break out Epics into sub-tasks and link related designs to Phab tasks
 * 16) * Conceptual document available on-wiki, linked to related Phab tasks, etc
 * 17) * Most major unknowns should be identified, remaining work is understood
 * 18) Development
 * 19) * Most functionality delivered to internal users for dogfooding/feedback
 * 20) * Scope trimmed to final size (remove tickets from board as necessary)
 * 21) Feature Freeze
 * 22) * Only minor bugs and edge cases remain or added are to scope
 * 23) * Initial QA and design review completed on all epics
 * 24) Code Freeze
 * 25) * Do pre-release smoke test and beta
 * 26) * Monitor beta release crash reports for at least three days before another beta release
 * 27) * Remove all “nice to haves” from the board
 * 28) * Only new tickets come from QA or tester feedback
 * 29) * Create a new branch from develop named as the version number for the release; any changes to the release are done as pull requests/patches targeted to this branch
 * 30) * Finalise marketing messages and materials, update app store assets
 * 31) Release Call
 * 32) * Final check with engineers
 * 33) * Actual release happens
 * 34) * Release notes publicised
 * 35) * Documentation updated
 * 36) Release
 * 37) * Duties should be rotated amongst engineers so that everyone understands the process.
 * 38) *Minor/bug-fix releases will be once per month, incorporating whatever bugs have been fixed and minor improvements have been made, that have passed QA and design review by the time we cut the beta. We will submit to beta on the Monday of the last week of the month, monitor for a few days, and submit to prod on the last Thursday if crashes/ratings/etc look fine.
 * 39) *Major feature releases will go out as and when the feature is completed as per checklist above, and needn't wait till the end of a month.

Rituals
These meetings ensure that the team maintains regular communication and has time for planning and board upkeep.