Talk:Wikimedia Apps/Team/Android/Release process

iOS Release Process
See https://etherpad.wikimedia.org/p/iosappcadencenojoke for notes from the 1-April-2015 meeting.

As discussed during the 1-April-2015 meeting, new regression tests should be added to the Google Sheet.

Kristen
I love that we're starting to formalize this.

However, reading between the lines of the proposal as written, I hear "we have little to no confidence in our code and not much trust in our team roles". My tl;dr is: 1.) can we focus on getting more of the "safety" and confidence pieces covered earlier in the process/during the sprint (earlier testing, better test coverage, signoff) so that the beta testing becomes more of a formality rather than a major undertaking and 2.) could we scale down the voting and escalation pieces to streamline things and hand off more of the testing pieces to QA? KLans (WMF) (talk) 18:28, 1 April 2015 (UTC)


 * I'm going to remove the voting concept. We're planning to stage gate all feature cards through separate columns, which in a way means anyone can block. But in practice the Product Manager can overrule. --ABaso (WMF) (talk) 19:37, 1 April 2015 (UTC)

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 bugfix code cutoff


 * 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. The corollary of this is the engineers need to be judicious about not polluting the code; there are many ways to deal with this.


 * Product manager, lead designer, lead QA, and lead iOS engineer do final verification for crashes and serious regressions, flagging blockers.


 * Thursday morning: Product Manager gives final go/no-go.


 * If by 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
If we didn't submit for formal App Store review in week 1, then in week 2, we follow the same process as week 1, mandatorily submitting a release for formal App Store review on Thursday week 2 of the iteration.

If we're for some reason still blocked by Thursday week 2 of the iteration, we notify Directors of Engineering, Product, Design, and Platform, plus the Manager of Release Engineering.

Feature cutoff?
Feature cutoff for week 2 of a sprint Thursday afternoon 3 PM San Francisco would allow for Friday to be a day for experiments and any "last minute" bugfixes.

More Process
During the current sprint, Corey and Brian are working on systematizing build stuff, and there will definitely be a transition period to make things more automated. Additionally, Brian has noted the need to set firmer release criteria. And we're all aware of the need for other automated quality criteria But these are the broad strokes of what I think could work for the basic process.