Wikimedia Apps/Team/Android/Release process

This page documents the release process for the Mobile Apps Team.

Alpha releases
Alpha apks are built automatically after patches get merged to master every 15 minutes and are available at android-builds.wmflabs.org.

Production releases
Production releases are promotions from beta by the product owner.  Check out the last beta and push the prod tags.  Promote the Play Store alpha build to production and submit the Appstore build. 

Beta release
 Announce on that a new beta build is in progress and that merges should be held. Prepare the workspace.  Increment the version code.  Push the version increment patch.  +2 the patch.</li> Set the environment variables. </li> Build the beta, production, and partner flavors. This script is confidential because some partners wish to maintain anonymity. However, it looks something like this: </li> Start an alpha build.</li> Start the release notes Etherpad cooking. </li> Add a release card to the current sprint.</li> Launch a few emulators (with generous disk space and low resolution) for APIs 17, 19, and 21 and connect all physical devices including a Fire OS device and the latest API. Note: CI tests on API 15. For physical devices, enable the "stay awake" developer option. On one device, enable the "don't keep activities" developer option. TODO: set this in script.</li> Verify the number of physical and virtual devices connected is expected. </li> Uninstall test apks with potentially mismatched signatures. </li> Run all tests on all devices (~20 minutes). </li> Install beta and prod apks on all devices. </li> Preserve the local test results. </li> Review the test results including all screenshots. </li> Do some light manual testing, including search, saved pages, history, nearby, beta-only and prod-only features, Content Service-only and MediaWiki-only features, light and dark mode, upgrade from a previous version, and new features and churn areas identified when generating release notes.</li> Push the tags. </li> Preserve the apks on releases.wikimedia.org. </li> Upload the releases to Google Drive too. </li> <li>Verify the files were uploaded and move the old files to the "old" folder.</li> <li>Upload the -beta- to the Play Store beta production. TODO: automate.</li> <li>Upload the -r- to the Play Store production alpha. TODO: automate.</li> <li>Upload the -amazon- to the Appstore upcoming. TODO: automate.</li> <li>Add the release to Mobile/Release_history under the Android section's "Release notes&lt;/translate&gt;". echo "|- &lt;translate>Release candidate alpha&lt;/translate>" With the following commit message: </li> <li>Send email to mobile-l, cc android, and bcc volunteer contributors. TODO: templatize.</li> <li>Send email to TSG. TODO: templatize.</li> <li>Send test results to android.</li> <li>Wait ~2 hours and then see the live update in Google Play Store.</li> </ol>
 * Android || $APP_VER-r-$APP_DATE || || $APP_DATE || $(md5sum $RELEASE_DIR/wikipedia-*-releasesprod-*.apk|sed -r 's%(\W).*%\1%')||
 * 1) TODO: automate.

iOS
See the following:


 * https://etherpad.wikimedia.org/p/iosappcadencenojoke (1-April-2015)
 * https://etherpad.wikimedia.org/p/qaoniosrocks (2-April-2015)
 * https://etherpad.wikimedia.org/p/iosreleasing (8-April-2015)

Cards
Effective mid-sprint 54 on iOS, Phabricator cards on iOS will go through Code Review, QA Signoff, and Design Sign Off before they go to the Ready for Review (Product Manager signoff). We'll tweak the process as necessary. Important points about this:


 * The Description field should contain a link to the design card. The design card should contain mocks, expected user interaction behavior, and any finer points that may escape the attention of engineers (e.g., gradients, font faces, transition durations, etc.). It should address phone and tablet form factor, as well as portrait and landscape mode.
 * The spec should be noted to reading-wmf one week before a sprint starts to allow feedback
 * The Product Manager and Designer will ensure the Description field contains sufficient Acceptance Criteria for QA to know what to test (if not already captured on the Design card), and software engineers should update if there are specifics relating to the patch associated with a card.
 * The primary code author must test on iOS 6 and iOS 8 (on 1 form factor at least, both phone and tablet if UI related). Code reviewers must test on at least one device. The QA analyst must test on iOS 6, iOS 7 (simulator, less emphasis), and iOS 8 on a phone form factor, and must test on at least one version of iOS for the tablet form factor (ideally, both iOS 8 and iOS 7, though, for tablet form factor instead of just one iOS version). Recommendation: test daily.
 * Alpha builds will be available each weekday morning, so QA should be able to review cards in the QA column at that time. If a crash occurs, QA should start the app back up and submit the crash via HockeyApp.
 * Design to sync with QA twice per week on any cards in its column for sign off. One approach: test alpha Wednesday and Friday of week 1, Tuesday and Thursday of Week 2 for all cards in Design column. If a crash occurs, Design should start the app back up and submit the crash via HockeyApp.
 * The developer working the card should shepherd it through the columns (e.g., prompt QA or Design if necessary). Engineers, QA, Design, Product Manager, and Scrummaster should be online on IRC during normal business hours in case they need to be nudged about a card.
 * Work product may be rejected and moved back to To Do, with a Comment explaining why, if the implementation did not match the specification. Otherwise, new cards (Tasks) should be filed if follow-on work is required, and the work will be prioritized for later implementation (potentially in the current sprint, but potentially in a later sprint); bug reporting guidelines should be used for such follow-on work as appropriate.
 * If sign off is not required from a particular stakeholder (e.g., Design not needed for data layer testing), the Description card should indicate as much, and the card should be dragged to the appropriate column.
 * The engineer should indicate low level technical testing steps as appropriate to the technical depth of the card.
 * If necessary, note whether the card is high risk.
 * Features that we know can't be used by the end of a sprint should not submitted for TestFlight or App Store.
 * Update the iOS Test Cases for regression testing as necessary.

Philosophy
Release every two weeks. Keep it simple. Give a solid reason if blocking a release. But it's okay if it has to be blocked. This is how we roll.

Feature cutoff is Friday afternoon 3 PM San Francisco on week 2 of the sprint. Cards that don't make it by then get moved to the next sprint or backlogged. Enjoy your weekends!

Release card
There will be a release checklist card added to every sprint board. This should be linked into the roadmap board.

Week 1 of iteration

 * Monday morning: Tech Lead engages Specialists Guild, informing them that Wikipedia Mobile will be released via TestFlight the following day and that their testing results are requested to be returned by Wednesday no later than noon.


 * Monday afternoon: 3 PM San Francisco last minute bugfix code cutoff for prior sprint's work. Ideally, there won't actually be any new code on Monday pertaining to the prior sprint.


 * Tuesday morning, 9:30 AM San Francisco time: whatever's merged into the release branch goes into both Wikipedia Beta for TestFlight external testing and Wikipedia Mobile (stable) for TestFlight internal upgrade smoketesting as the release candidate (instructions). The corollary of this is the engineers need to be judicious about not polluting the code; there are many ways to deal with this.


 * Thursday afternoon at 3 PM San Francisco time there hasn't been serious badness identified (iOS engineering to report all crashes and user reported feedback), we then submit this release candidate to Apple.

Week 2 of iteration
Thursday morning: Product Manager gives final go/no-go for submitting for releasing.

Release
The app should be submitted during early business hours Monday through Thursday in San Francisco, but not Friday, Saturday, or Sunday. Typically this actually should happen the first week of a sprint. Note that if Comms is needed for a big announcement for a given release, they need a heads up well ahead of time, with timely updates as the ship date approaches (the final 5 business days leading up to big announcements are pretty critical with history as a guide). Big splashes don't happen every sprint (more likely, just quarterly), and for most sprints, social media only announcements with less time-pegged blog posts (if any blog post) is fine.

If we hit blockers
Notify Comms, update the release card, etc.

Version Bumps
Note that TestFlight version bumps on the x.y (major.minor) part of the x.y.z version require formal Apple review before they can become available to external testers. Therefore, if a major.minor bump is needed, the TestFlight toggle needs to be flipped in iTunes Connect to get that in the queue with sufficient lead time so that Tuesday cutpoints aren't missed. Know what you're doing before you toggle switches. You don't want to end up effectively disabling in-flight testing on release candidates.

Unit tests
Broken unit tests on the build server constitute a broken build and must be fixed to make work product shippable.

Open questions

 * Branching strategy to handle rejected cards. Realistically, if rejected cards are treated within the same sprint they're worked, no special branching is required. Daily (QA) and twice weekly (Design) feedback should help to avoid serious problems occurring too late in the sprint.
 * Branching strategy for the week 1 or week 2 swarms when they're required. Presently, the thought is to just branch from the corresponding tag and do all work on that branch, merging such fixes upstream to master as well.
 * The format of what's required in the Description field of cards in Phabricator and what constitutes a sufficient Design card (Trello) isn't fully defined, although most of it is specified above. This said, a checklist could potentially help reduce ambiguity.
 * Is a "Spec" column needed on the main iOS board? It would be before the Next Sprint column to reflect when a design specification is still required. Likewise, is an Estimation and a Released column needed in the main iOS board? This way we have a clear liner progression on the main board from Needs Triage to Released.
 * Is full regression testing (TSG) required in case submission for app store review was pushed to week 2 of the sprint? Probably not, as the entire team should be swarming on the issues that caused the delay.