Talk:Wikimedia Apps/Team/Android/Release process

iOS Release Process
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)

Week 1 of iteration

 * Monday morning: Product Manager engages Specialists Guild, informing them that Wikipedia Beta 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 master goes into both Wikipedia Beta for TestFlight *external* testing and Wikipedia Mobile (stable) for TestFlight internal upgrade smoketesting as a 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 iOS engineering team verify for crashes and serious regressions; serious issues are SWAT-team style fixed


 * Wednesday afternoon: iOS Engineering holds vote on whether Tuesday release candidate is safe to ship; if there were serious bugs fixed since the Tuesday morning release candidate, iOS Engineering holds vote on whether the Tuesday release plus those bugfixes is safe to ship. It must pass by a vote of 3 out of 4.


 * Thursday morning: Product Manager, Design, QA, and iOS Engineering Tech Lead vote on releasing. It must pass by a vote of 3 out of 4. Following this vote, if the Tuesday release candidate was sufficient, that is submitted for formal App Store production review. If the Tuesday release candidate had to have bugfixes, then a release candidate with the serious bugfixes on top is cut for both Wikipedia Beta for TestFlight *external* testing and Wikipedia Mobile (stable) for TestFlight internal upgrade smoketesting.


 * Thursday afternoon: if we didn't already submit for formal app review in the morning (i.e., there were serious intervening bugfixes), that means Thursday morning we had cut for both Wikipedia Beta for TestFlight *external* testing and Wikipedia Mobile (stable) for TestFlight internal upgrade smoketesting. And 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 for some reason we're still at an impasse, then in week 2 of the iteration we follow the same process, mandatorily submitting a release for formal App Store review on Thursday week 2 of the iteration.

If we're for some reason still at an impasse by Thursday week 2 of the iteration, the impasse is escalated to the Director of Engineering, the Director of Product, the Director of Design, and the Manager of Release Engineering plus Director of Platform.


 * Feature cutoff for current sprint at Thursday afternoon: 3 PM San Francisco? This 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.