Wikimedia Apps/Team/Android/AndroidReleasePhases

Development Timeline

Week A	Monday: Release beta. All week: QA / signoffs / monitor beta rollout / fix bugs / regression testing.
Week B	Wednesday: Release to production, monitor.

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.

Phabricator ticket flow

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, Monday: Check in on lingering tickets (including the testing ticket) - remind people that ideally we are ready to release on Wednesday.
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.)
Write release notes based on all tickets that are part of this release.
Build beta (ensuring it gets a tag) and release the beta.
Create ticket for regression test.
If there was a Room database version update, or any bit of functionality that depends on the user upgrading the app, create a ticket for an upgrade test.

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.
Close items on Phabricator board from this cycle: Close tickets in "ready for release" column (mark as "resolved").

Release duty rotation

Dmitry
Cooltey
Sharvani

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.

Initialisation
- Discuss concept with PM/engineers/UX research/analytics/RI and other teams to be informed
- Prepare rough concepts/wireframes as needed to aid discussion
- PM/analytics/UX research agree initial set of research questions (qual and quant)
Research
- Present design proposal to engineers/design research/analytics for feedback
- Engineers begin technical discussions
- Write placeholder Epics
- Create prototype for user testing (preferably using InVision or similar)
- Initial evaluative user testing
Specification
- Engineers agree on technical implementation details (and create mock APIs, etc)
- Finalised designs and user flows completed and available in Zeplin (feedback to design as needed from engineers)
- Analytics specifies tagging scheme based on research questions
- Break out Epics into sub-tasks and link related designs to Phab tasks
- Conceptual document available on-wiki, linked to related Phab tasks, etc
- Most major unknowns should be identified, remaining work is understood
Development
- Most functionality delivered to internal users for dogfooding/feedback
- Scope trimmed to final size (remove tickets from board as necessary)
Feature Freeze (Week A Monday-Wednesday)
- Only minor bugs and edge cases remain or added are to scope
- Initial QA and design review completed on all epics
Code Freeze (Week A Wednesday - Week B Tuesday)
- Do pre-release smoke test and beta
- Monitor beta release crash reports for at least three days before another beta release
- Remove all “nice to haves” from the board
- Only new tickets come from QA or tester feedback
- 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
- Finalise marketing messages and materials, update app store assets
Release Call (Week B Wednesday)
- Final check with engineers
- Actual release happens
- Release notes publicised
- Documentation updated
Release (Week B Wednesday - Friday)
- Duties should be rotated amongst engineers so that everyone understands the process.
- 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.
- 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.

Name	Frequency	Duration	Description	Goals	Special Guests
Grooming	Mondays	30 min	Team meets to triage work that comes into the backlog and check on the release board. If there's time, groom the backlog.	Triage tasks Groom tasks	n/a
Combined Apps standup	Mondays	30 min	Team meets with the iOS team and support members to call out any dependencies or blockers.	Sync up on current work Identify and share blockers	QA CRS
Planning	Tuesdays	50 min	Team meets to set up a plan for the week, check on development phase/release board status, and make sure support members are informed.	Decide on scope Update the board Document action items	data analyst QA (optional)
Slack standup	Wednesdays, Fridays	n/a	Team responds to a Slack bot reminder to report on what they did yesterday and what they are doing today.	Share what you've worked on Share what you'll be working on Share what's blocking you	n/a
Task Sync	Thursdays	30 min	Team meets to review tasks in progress and dive into blockers.	Update the board Discuss issues	data analyst (optional)
Retrospective	every other week on Thursdays	30 min	Team meets to reflect on past two weeks, celebrate successes, and consider improvements.	Discuss what's working well Discuss what could be improved Establish next steps to implement change	as needed
Team Time	every other week on Thursdays (alternating with retro)	30 min	Social time, occasionally repurposed for extra discussion time if needed.	Chat with teammates	as needed