Page MenuHomePhabricator

iOS Continuous Integration MVP
Closed, ResolvedPublic


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.

  • Summary
  • Rationale
  • Success Metrics
  • External Dependencies
  • Unknowns
  • Product Plan
    • Prototyping
    • MVP
    • User stories
    • User Story Phab Tickets
    • Metrics Implementation
    • Metrics Phab Tickets
    • Estimates
    • Delivery Date


As a Wikipedia iOS project contributor, my changes are automatically deployed to testers after being merged.

Goal Visibility

Internal readership goal (see Q1 themes)


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.


  • T105351 Test coverage: 18.06%
  • Number of unit tests: 189
  • T105351: Gather metrics as part of testing/CI Done via codecov
  • 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)

Abandoned code quality since OCLint is not cooperating with our project at the moment. Might revisit later.
- [ ] T106418: Code quality (see cyclomatic complexity, function length, etc. see OCLint for details)

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


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 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 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:


(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.

Prototyping1 week DONE
User Testingn/a
Development2 weeks
Beta Testing4 weeks

Delivery Estimate

Two weeks from when 4.1.7 is submitted for App Store review, so approximately August 7th.

Event Timeline

BGerstle-WMF updated the task description. (Show Details)
BGerstle-WMF raised the priority of this task from to Needs Triage.
BGerstle-WMF added a subscriber: BGerstle-WMF.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 13 2015, 3:44 PM
BGerstle-WMF renamed this task from [EPIC] iOS Continuous Integration MVP to [EPIC] Apps Continuous Integration MVP.May 13 2015, 3:51 PM
BGerstle-WMF updated the task description. (Show Details)
BGerstle-WMF set Security to None.
BGerstle-WMF triaged this task as High priority.Jun 15 2015, 8:40 PM
BGerstle-WMF updated the task description. (Show Details)
BGerstle-WMF added subscribers: hashar, greg, dduvall and 2 others.
BGerstle-WMF renamed this task from [EPIC] iOS Dev Infrastructure MVP to iOS Dev Infrastructure MVP.Jul 9 2015, 3:07 PM
BGerstle-WMF lowered the priority of this task from High to Normal.
BGerstle-WMF raised the priority of this task from Normal to Needs Triage.
BGerstle-WMF updated the task description. (Show Details)
BGerstle-WMF renamed this task from iOS Dev Infrastructure MVP to iOS Continuous Integration MVP.
BGerstle-WMF updated the task description. (Show Details)

@Fjalapeno @dr0ptp4kt @greg I think the epic is a bit less rough now if you want to skim and offer suggestions on metrics and such.

greg added a comment.Jul 24 2015, 3:12 PM

I'll offer feedback here after we have our retrospective on the decision to use GitHub.

MBinder_WMF added a subscriber: MBinder_WMF.

Archived Mobile-App-Goals so tagging iOS board. Feel free to decline.

MBinder_WMF closed this task as Resolved.Jun 30 2016, 5:50 PM