Continuous Delivery Pipeline for Mobile Applications
Submitted by sudeep sr (@sudeepsr) on Thursday, 4 August 2016
Section: Full talk (40 minutes) Technical level: Intermediate Status: Rejected
Why we needed it
“An engineer in an internet company should be able to think of ideas, build prototypes, translate feature specs (or discussions) into workable components, design architecture, write good code, test what has been built (ideally TDD), review code, monitor servers, scale applications, analyze logs, plan capacity, design databases, implement and use caching efficiently, tweak web servers, tweak databases, build fast, release faster, learn new tech to ride new waves etc .” Vibhore Sharma, our CTO, blogged this in 2011. Half a decade has passed but this is still very true and I think will be so even couple of decades down the line. This talk presents how one can design and benefit from continuous delivery systems for Android apps.
Very often in mobile apps, we see that builds are generated by developers on their local machines which are then sent out to testers or to play store. This is quite risky and error prone esp. when working in larger teams. An app like ours uses a couple of third party sdk that can have different versions floating. The standard steps for building an app such as clean, compile, release, install etc… have been automated on a scheduled or triggered basis. It has empowered product owners to pull a fresh stable build any time they want to.
As the rule says, whatever can be unit tested should be unit tested. Besides functional tests, we also write unit and integration tests. In order to get the full benefit of unit tests, the test suite is run as part of build process daily. Developers may accidentally check in code that does not work, so we test early and often, to ensure that the code committed into repository is healthy.
After the test cases pass, static code analyzers like Lint are run to check the code quality and potentially mark the build as unstable or fail if some errors were introduced in the latest commit.
BVT (Build Verification Testing)
We also have Build Verification tests in place which run on every new build. It verifies that build is testable before it is released to test team for further testing. These test cases are core functionality test cases that ensure application is stable and can be tested thoroughly.
The functional tests are executed daily on our production and test environments. These tests are managed using TestLink tool, scheduled using Jenkins and executed using Appium.
After the execution of test cases, code coverage reports are generated using JaCoCo and Slather. All teams have been given a minimum code coverage target. As a next step we will fail a build if anytime the code coverage falls below a defined threshold value. Coverage trends will be published to all at the end of each iteration.
If the build is passes all the above mentioned steps, then it is marked as success and distributed via email to QA team/ product owners to do final testing.
Automated Build, Test and Release Process
When software development processes are automated, they are repeatable, reliable and can be run frequently. By automating the build and test processes we not only have saved time, but have also enforced standards. It also gives developers an immediate feedback on their work.
-How a typical workflow looks like -Why this approach is error prone -How we did it -Using Jenkins tool automating build processes, continuous integration and automated deployments -Test results, coverage trends and code analysis reports -step by step guide of how to integrated various tools for android apps
Sudeep has >5 years of extensive experience in design and development of Android Applications. He is expert in designing architecture styles like MVC, MVP, MVVM, Sudeep is passionate about implementing high performance, data driven, native android apps. Currently working as android Technical Lead.