Wikimedia Apps/Team/Android/AndroidReleasePhases

Development Timeline
At any given time, however, two releases are underway. Development work for the following release is happening during the two weeks of completing each release.

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`.

If there is are no new changes when it's time to create the beta, the Android team will discuss how to proceed. Most likely options would include skipping a release cycle, or delaying the start of the release cycle to the following week.

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 A, Monday: See checklist below.
 * Week A, Tuesday through following Wednesday: Monitor beta feedback/bugs, check for crashes, give updates to entire team. (QA's regression testing, QA ticket testing, and PM signoffs are happening during this time.)
 * Week B, Wednesday: See checklist below.
 * Week B, Wednesday through Friday: Monitor production bugs, check for crashes, give updates to entire team.

Checklist for Monday of Week A

 * Move items on Phabricator board for the cycle: Move tickets from "Merged and Waiting" to "QA signoff". If there are no tickets in "Merged and Waiting", inform the entire Android team (including PM) so we can decide next steps. (We might skip a cycle, we might move the start of the cycle to the following week.)
 * Create a regression testing ticket and assign to Anthony.
 * Write release notes based on all tickets that are part of this release.
 * Build beta (ensuring it gets a tag) and release the beta.

Checklist for Wednesday of Week B

 * Ensure QA/signoff tickets are complete. ("Did not pass QA", "Design signoff", "QA signoff", and "Ready for PM signoff" should all be clear of tickets.) Confirm regression testing was completed (check the ticket created on Monday), and that it passed.
 * If any of these are not complete, DO NOT PROCEED and inform the entire Android team (including PM) so we can decide next steps.
 * Release app to production on all 4 app stores.
 * Move items on Phabricator board from this cycle: Close tickets in "ready for release" column (mark as "resolved").

Release duty rotation

 * Dmitry
 * Sharvani
 * Cooltey

Use the weekly team Planning meeting to adjust this rotation as needed.

Android team development phases
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 (Week A Monday-Wednesday)
 * 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 (Week A Wednesday - Week B Tuesday)
 * 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 (Week B Wednesday)
 * 32) * Final check with engineers
 * 33) * Actual release happens
 * 34) * Release notes publicised
 * 35) * Documentation updated
 * 36) Release (Week B Wednesday - Friday)
 * 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.