= 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/CD 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
Need to finalize. Unless support is available, will likely use Travis.
== 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)
== 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
- [x] Crashes per day: **Done** already measured on HockeyApp (including timelines across versions)
- 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)
=== Stretch Metrics
Metrics we'd like to know about, but are difficult 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
== Timeline Estimate
| Task | Estimate |
| ----- | ---------- |
| Prototyping | //1 week// **DONE** |
| User Testing | n/a |
| Mockups | n/a |
| Development | 2 weeks |
| Beta Testing | 4 weeks (to get metrics after CI is implemented) |
== Delivery Estimate