The document discusses the principles and practices of Continuous Delivery (CD) in the context of mobile app development, emphasizing the importance of integrating automation in building, testing, and releasing software. It highlights the need for a well-defined branching strategy in Continuous Integration (CI), the use of platforms like Git, and the challenges associated with iOS and Android environments. The document also outlines the differences in app store processes between Google Play and Apple’s App Store, along with considerations for maintaining app versions in relation to user and OS update cycles.

1. 18 September, 2015
Towards Continuous Delivery in Native Mobile Apps

2. “ContinuousDelivery is a softwaredisciplinewhere you build
softwarein sucha way thatthe softwarecan bereleased to
productionat anytime” – Martin Fowler
• Discipline – CD is not just a set of tools, it’s a practice.
• Build – The development/testcycle.
• Release– Distributing your softwareto users.
• Production – Softwareis in the hands of your users.
What is Continuous Delivery?

3. Continuous Integration
“Askingexperts to do boringand repetitive,and yet technically
demandingtasksis the mostcertainwayof ensuringhumanerror
thatwe canthink of, shortof sleep deprivation,or inebriation.”–
David Farley
• CI is the process ofintegrating, building,and testing code
within the developmentenvironment.
• CI adds value from the automationof these processes.
• There are both cultural and technical considerations – these
must go hand-in-hand.

4. CI – Integration 1
• Everything should be under Source Control – This includes
code, tests, build scripts etc.
• A well-definedbranching strategyis vitalas the number of
developers grows.
• Adhering to a branch naming strategyalso brings extra benefits
(i.e. when auditing codebase,generatingchangelogsetc.).
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

5. CI – Integration 2
• We use git – both github and gitlab.
• Both these platformsprovide some form of pre-merge
validation(i.e. pull request / mergerequest etc.).
• Product must be buildable and alltests must pass.
• Rapid feedback cycle to developers(test results, static analysis
etc.).
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

6. CI – Building 1
• Building your app should be triggeredautomaticallyon every
change.
• Android – LearnGradle. Eventhough Android Studio givesyou
this out of the box, developersshould spend time
understanding how Gradle actuallyworks. Very flexible and
easilyextendable.
• iOS – Trickier.Developersshould understand how to build their
app outside of Xcode. Heavy dependence on an IDE makes
automationmuch more difficult. (Availabletools:xctool,
fastlane etc.)

7. CI – Building 2
• Takecareof your build environments
• Android– Can build on most platforms (Linux, Windows, OSX)
• NoUI
• Lightweightenvironment
• Virtualisationand/orcloud–nolimittoscale
• iOS – Requires full OSX environment + Xcode. Possible to
virtualise, but only on Mac hardware.
• FullUI
• Comparativelyheavy+fragileenvironment
• Novirtualisation–scalinglimitedbyavailablehardware

8. CI – Building 3
http://www.gizmodo.in/news/This-Custom-Datacenter-Rack-Has-160-Mac-Minis-Crammed-Inside-of-It/articleshow/19223824.cms

9. CI – Testing 1
• Unit Tests
• Getas much valueas possible from your Unit Tests.
• Collectingcoveragedata potentiallyprovides you extra
possibilities (e.g. validatingfeaturetogglesetc.)
• Android – Robolectricis your friend. Mocks out the Android
system and effectivelyallowsyou to run directlyagainsta JVM.
No emulatorrequired.
• iOS - xctool,XCTest etc. Requires a full OSX dev environment.

10. CI – Testing 2
• Integration Tests / UI Tests
• Generalconcerns:
• High levelof maintenancerequired.
• Testing business logic through the UI.
• Tests areoftenvery fragile– not alwayssuitable as part of
your automatedvalidationprocess.
• In a lot of cases, this is betterserved by manual/usability
testing.

11. CI – Testing 3
• Approaches
• Calabash, Appium etc – need to be compiled into your test
builds. Theoreticallytests can be cross-platform. Little
knowledgeof app architecturerequired.
• Native frameworks(UI Automation/UI Automator)– Tests
are platform specific. Some app knowledge required.
• Code-level integration – Calling test methods directly. Test
methods provided as part ofdevelopment. High-levelof app
knowledgerequired.

12. From CI to CD
• Through CI we can validatethat our app is buildable and that
our tests were successful.
• Your main development/trunk branch should bepotentially
releasableat any stage.
• Store Distribution
• Apple and Googleboth provide the platformfor deploying
to users.
• Reviewprocesses etc. can delay/blockthe process.
• Building and publishing store/marketingassets.
• Can we continuously deliverto the Stores?

13. • GooglePlayStore
• Provides public API’s and DeveloperConsole for almost all
functionality.
• Alpha/Beta testingchannels.
• Stagedrollouts – scale up any single releasefrom 1% to 100%.
• Rollouts can be halted atany stage.
• Reviewprocess usually fairly light. Afterdeliveringa build you
have a high levelof control overhow it is deployed.
CD – Play Store

14. CD – App Store
• Apple App Store
• Provides NO public API’s. (Although tools likefastlaneexist).
• TestflightBeta testing.
• NO Stagedrollouts.
• Heavy reviewprocess. App must be reviewedbefore it is
availablefor beta testing.
• Afterdelivering a build you have little control overhow it is
deployed.

15. Concerns
• App update cycles.
• Users update more rapidly with high frequency apps –
need tosupport fewerliveversions.
• Apps with low frequency usage oftenneed to support
many more live versions.
• OS update cycles
• iOS - ~70% of users update to latestOS within 2 weeks.
• Android – Much more fragmented– likelyto require
supporting 5-6 majorOS versions at any one time.

16. Condor
• Condor - Our in-house CI/CD Service using Jenkins as the
backend CI server.
• Condor-Backend auto-generatesJenkins jobs based on project
configurationstored in repo alongside code-base.
• Condor-Client configuresthe desired build environment, runs
build scripts and reports results back to Jenkins/Sonar etc.
• All build scripts are treatedas code – versioned and validated
the same as any other change.

17. Further Reading
• Duvall, Paul M (2007) – ContinuousIntegration.Improving
SoftwareQualityand ReducingRisk. Addison-Wesley.
• Humble,Jez; Farley, David (2010) – ContinuousDelivery:
ReliableSoftwareReleases ThroughBuild,Test and
Deployment Automation.Addison-Wesley.
• ThoughtworksContinuous Deliverywebinar
serieshttp://www.thoughtworks.com/products/webinars/introduction-continuous-
delivery
• The Guardian: DeliveringContinuous Delivery,continuously
https://www.theguardian.com/info/developer-blog/2015/jan/05/delivering-continuous-
delivery-continuously

18. quartermile one
15 lauriston place
edinburgh eh3 9en
tel: +44 (0)131 252 5353
fax: +44 (0)131 252 5354
follow us @skyscanner
join us on
facebook.com/skyscanner
Thank you!
Phillip Wheatley
phillip.wheatley@skyscanner.net
@convict7421