Change Details

= Definition Progress The following is a checklist for completion of the definition of the Epic. Make sure to check these off as you complete each item. - [x] Summary - [x] Rationale - [x] Success Metrics - [x] External Dependencies - [x] Unknowns - [x] Product Plan -- [x] Prototyping -- [x] MVP -- [x] User stories -- [x] User Story Phab Tickets -- [x] Metrics Implementation -- [x] Metrics Phab Tickets -- [x] Estimates -- [x] Delivery Date = Summary Set up continuous integration for the Wikipedia iOS app to ensure that: - Developers have all their patches tested automatically as part of code review - Code cannot be deployed when tests are broken - Test coverage is measured and visualized so it can be used as a rough metric for code healthiness == Goal Visibility Internal readership goal (see [Q1 themes](https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm_Distillation)) = Rationale Following our discussions at the Lyon Hackathon (T98974) and based on Readership's [Q1 theme](https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm_Distillation) to "Improve developers' ability to develop features quickly and reliably to serve readers across desktop, mobile web and apps" we're going to get our CI infrastructure to an "MVP" state = Success Metrics - Test coverage velocity - Crash rate - Average code review duration - Overall developer confidence = External Dependencies Release engineering (Gerrit, Zuul) or Travis CI = Unknowns List out anything you don't know that will need to be understood before the Epic can be completed. = Product Plan Set up continuous integration so developers can start getting immediate feedback on and incentive to write tests. Once that's setup, improve continuous delivery to facilitate manual QA and beta testing. == Prototyping @BGerstle-WMF set up a fork of the Wikipedia iOS GitHub repo to work with Travis CI. Results were encouraging: https://travis-ci.org/bgerstle/apps-ios-wikipedia == MVP (See blocking tasks) == User Stories (See blocking tasks and their blocking tasks) == Metrics Implementation & Tasks - [ ] T105351: Test coverage - [ ] T106418: Code quality (see cyclomatic complexity, function length, etc. see [OCLint](http://oclint.org/) for details) - [ ] T105351: Gather metrics as part of testing/CI - [ ] Developer confidence //take a baseline survey, and/or use notes from previous retros// (coordinate w/ max binder to integrate into health check on July 29th) === Difficult Metrics Metrics we'd like to know about, but aren't sure how to measure. - Code review duration - Don't know how to get baselines for this (from Gerrit, ssh API?), more familiar w/ GH API (might even already be available) - Defect rate - Not only is this hard for us to measure, but our ability to find & report bugs is a bit lacking at the moment—so a positive trend might actually be a good thing - Community engagement - Mainly, we'd like to know if it went down as a failure metric, but like CR duration, could be hard to get baselines == Timeline Estimate Once the 4.1.7 update is released (T106106), we will start chipping away at these tasks. We have some capabilities already in place, so it should only be a matter of implementing metrics, gathering baselines, then hooking up Travis to run it all as part of code review. | Task | Estimate | | ----- | ---------- | | Prototyping | //1 week// **DONE** | | User Testing | n/a | | Mockups | n/a | | Development | 2 weeks | | Beta Testing | 4 weeks | == Delivery Estimate Two weeks from when 4.1.7 is submitted for App Store review, so approximately August 7th.

= Definition Progress The following is a checklist for completion of the definition of the Epic. Make sure to check these off as you complete each item. - [x] Summary - [x] Rationale - [x] Success Metrics - [x] External Dependencies - [x] Unknowns - [x] Product Plan -- [x] Prototyping -- [x] MVP -- [x] User stories -- [x] User Story Phab Tickets -- [x] Metrics Implementation -- [x] Metrics Phab Tickets -- [x] Estimates -- [x] Delivery Date = Summary As a Wikipedia iOS project contributor, my changes are automatically deployed to testers after being merged. = Goal Visibility Internal readership goal (see [Q1 themes](https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm_Distillation)) = Rationale There have been a number of incidences shaking developers' confidence in the stability of the codebase, especially the 4.1.0 & 4.1.6 releases, but also minor things like basic assumptions about legacy code behavior. We hope setting up continuous integration will give developers immediate feedback on and incentive to write unit tests. Feedback on changes which includes test results, test coverage, and code quality metrics should give a clear signal on the impact of those changes, as well as an overall quality trend for the codebase. This should help developers manage and gradually improve reliability while amortizing tech debt. = Metrics - [ ] T105351: Test coverage - [ ] T106418: Code quality (see cyclomatic complexity, function length, etc. see [OCLint](http://oclint.org/) for details) - [ ] T105351: Gather metrics as part of testing/CI - [ ] Developer confidence //take a baseline survey, and/or use notes from previous retros// (coordinate w/ max binder to integrate into health check on July 29th) == Acceptance Criteria Given I am working on the Wikipedia iOS repo When I submit or update my changes for code review Then CI should run a job **configured by iOS engineers** And the job should lint & test the changes And when the job finishes, I should post results back to the patch (+/- 1 CR and -1/+2 Verified) == Difficult Metrics Metrics we'd like to know about, but aren't sure how to measure. - Code review duration - Don't know how to get baselines for this (from Gerrit, ssh API?), more familiar w/ GH API (might even already be available) - Defect rate - Not only is this hard for us to measure, but our ability to find & report bugs is a bit lacking at the moment—so a positive trend might actually be a good thing - Community engagement - Mainly, we'd like to know if it went down as a failure metric, but like CR duration, could be hard to get baselines = External Dependencies Release engineering (Gerrit, Zuul) or Travis CI = Unknowns External dependency reliability (i.e. Travis and Coveralls/Codecov uptime). = Product Plan Following our discussions at the Lyon Hackathon (T98974) and based on Readership's [Q1 theme](https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm_Distillation) to "Improve developers' ability to develop features quickly and reliably to serve readers across desktop, mobile web and apps" we're going to get our CI infrastructure to an "MVP" state. GitHub and Travis were chosen as a pragmatic way to make these improvements while minimizing the load on the iOS and other teams. == Prototyping Prototyping Travis by setting it up on a fork of GH repo. If that goes well, move main dev workflow to GitHub and setup Travis there. @BGerstle-WMF set up a fork of the Wikipedia iOS GitHub repo to work with Travis CI. Results were encouraging: https://travis-ci.org/bgerstle/apps-ios-wikipedia == MVP (See blocking tasks) == User Stories (See blocking tasks and their blocking tasks) == Timeline Estimate Once the 4.1.7 update is released (T106106), we will start chipping away at these tasks. We have some capabilities already in place, so it should only be a matter of implementing metrics, gathering baselines, then hooking up Travis to run it all as part of code review. | Task | Estimate | | ----- | ---------- | | Prototyping | //1 week// **DONE** | | User Testing | n/a | | Mockups | n/a | | Development | 2 weeks | | Beta Testing | 4 weeks | == Delivery Estimate Two weeks from when 4.1.7 is submitted for App Store review, so approximately August 7th.

= Definition Progress The following is a checklist for completion of the definition of the Epic. Make sure to check these off as you complete each item. - [x] Summary - [x] Rationale - [x] Success Metrics - [x] External Dependencies - [x] Unknowns - [x] Product Plan -- [x] Prototyping -- [x] MVP -- [x] User stories -- [x] User Story Phab Tickets -- [x] Metrics Implementation -- [x] Metrics Phab Tickets -- [x] Estimates -- [x] Delivery Date = Summary Set upAs a Wikipedia iOS project continuous integration for the Wikipedia iOS app to ensure that:ributor, my changes are automatically deployed to testers after being merged. - Developers have all their patches tested automatically as part of code review - Code cannot be deployed when tests are broken - Test coverage is measured and visualized so it can be used as a rough metric for code healthiness == Goal Visibility Internal readership goal (see [Q1 themes](https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm_Distillation)) = Rationale Following our discussions at the Lyon Hackathon (T98974) and based on Readership's [Q1 theme](https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm_Distillation) to "Improve developers' ability to develop features quickly and reliably to serve readers across desktopThere have been a number of incidences shaking developers' confidence in the stability of the codebase, especially the 4.1.0 & 4.1.6 releases, but also minor things like basic assumptions about legacy code behavior. We hope setting up continuous integration will give developers immediate feedback on and incentive to write unit tests. Feedback on changes which includes test results, test coverage, and code quality metrics should give a clear signal on the impact of those changes, mobile web and apps" we're going to get our CI infrastructure to an "MVP" stateas well as an overall quality trend for the codebase. This should help developers manage and gradually improve reliability while amortizing tech debt. = Success Metrics -- [ ] T105351: Test coverage velocitye - Crash rate- [ ] T106418: Code quality (see cyclomatic complexity, function length, etc. see [OCLint](http://oclint.org/) for details) - Average code review duration- [ ] T105351: Gather metrics as part of testing/CI - Overall developer confidence[ ] Developer confidence //take a baseline survey, and/or use notes from previous retros// (coordinate w/ max binder to integrate into health check on July 29th) = External Dependencies== Acceptance Criteria Release engineerGiven I am working (Gerrit, Zuul) or Travis CI = Unknownson the Wikipedia iOS repo List out anything you don't know that will need to be understood before the Epic can be completed. = Product PlanWhen I submit or update my changes for code review Set up continuous integration so developers can start getting immediate feedback on and incentive to write tests. Once that's setup, improve continuous delivery to facilitate manual QA and beta testing. == Prototyping @BGerstle-WMF set up a fork of the Wikipedia iOS GitHub repo to work with Travis CI. Results were encouraging: https://travis-ci.org/bgerstle/apps-ios-wikipedia == MVPThen CI should run a job **configured by iOS engineers** (See blocking tasks) == User StoriesAnd the job should lint & test the changes (See blocking tasks andAnd when the job finishes, I should post results back to their blocking tasks patch (+/- 1 CR and -1/+2 Verified) == Metrics Implementation & Tasks - [ ] T105351: Test coverage - [ ] T106418: Code quality (see cyclomatic complexity, function length, etc. see [OCLint](http://oclint.org/) for details) - [ ] T105351: Gather metrics as part of testing/CI - [ ] Developer confidence //take a baseline survey, and/or use notes from previous retros// (coordinate w/ max binder to integrate into health check on July 29th) === Difficult Metrics Metrics we'd like to know about, but aren't sure how to measure. - Code review duration - Don't know how to get baselines for this (from Gerrit, ssh API?), more familiar w/ GH API (might even already be available) - Defect rate - Not only is this hard for us to measure, but our ability to find & report bugs is a bit lacking at the moment—so a positive trend might actually be a good thing - Community engagement - Mainly, we'd like to know if it went down as a failure metric, but like CR duration, could be hard to get baselines = External Dependencies Release engineering (Gerrit, Zuul) or Travis CI = Unknowns External dependency reliability (i.e. Travis and Coveralls/Codecov uptime). = Product Plan Following our discussions at the Lyon Hackathon (T98974) and based on Readership's [Q1 theme](https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm_Distillation) to "Improve developers' ability to develop features quickly and reliably to serve readers across desktop, mobile web and apps" we're going to get our CI infrastructure to an "MVP" state. GitHub and Travis were chosen as a pragmatic way to make these improvements while minimizing the load on the iOS and other teams. == Prototyping Prototyping Travis by setting it up on a fork of GH repo. If that goes well, move main dev workflow to GitHub and setup Travis there. @BGerstle-WMF set up a fork of the Wikipedia iOS GitHub repo to work with Travis CI. Results were encouraging: https://travis-ci.org/bgerstle/apps-ios-wikipedia == MVP (See blocking tasks) == User Stories (See blocking tasks and their blocking tasks) == Timeline Estimate Once the 4.1.7 update is released (T106106), we will start chipping away at these tasks. We have some capabilities already in place, so it should only be a matter of implementing metrics, gathering baselines, then hooking up Travis to run it all as part of code review. | Task | Estimate | | ----- | ---------- | | Prototyping | //1 week// **DONE** | | User Testing | n/a | | Mockups | n/a | | Development | 2 weeks | | Beta Testing | 4 weeks | == Delivery Estimate Two weeks from when 4.1.7 is submitted for App Store review, so approximately August 7th.