Simplifying Mobile Application Development with Continuous Delivery
|Steven G. Harris in Programming Wednesday, June 4, 2014|
In recent years, mobile application usage has evolved and grown tremendously. Unlike core IT systems (ERP, HR, etc.) that are under the close scrutiny of corporate IT, mobile applications come with very different requirements. What’s valuable and efficient today might not be what’s valued tomorrow: these more dynamic applications have to evolve constantly and adapt to user requirements if they are to avoid becoming legacy applications. As a consequence, developers have to be in a constant “discovery-mode” for trends in user requirements, experiment with what works or doesn’t work and iteratively improve the application.
Why Are Mobile Applications Different?
What about mobile application development is challenging? A number of additional constraints apply to mobile applications that traditional packaged software developers do not face.
- Typically applications need to be delivered on the two major platforms—iOS and Android—that have radically different tooling and programming characteristics. This makes software testing, in particular, a complex and arduous process. Mobile applications have to be tested on a range of form factors, device capabilities and mobile OS versions. This makes multi-platform testing a much more difficult problem to tackle than testing a few browser/OS combinations backed against a relatively well-respected HTML5 standard.
- Interaction with back-end services is heavily asynchronous and requires testing under varying, real-life network conditions.
- Location-based services, notifications and maps play a far more central role in mobile apps.
- Mobile applications typically have to be provided through the mobile vendor marketplace (such as Apple’s AppStore). These marketplaces incur their own friction; it can sometimes take days before a new version is made available to mobile users.
- Mobile users have particular and demanding requirements for performance and user experience that are often significantly different from those for web applications.
- Consumers might not be willing to give an application a second chance if it doesn’t work well. It will get uninstalled and probably never re-installed again. And it will not get rated very highly in the application marketplace. On the other hand, a web site probably has a better chance of being revisited to see if something has changed.
- While a Software as a Service (SaaS) application can revert back to a working version from a buggy release in seconds, a mobile application might have to go through a full release cycle within the mobile device vendor’s marketplace, creating lots of unhappy users while this process takes place. This is clearly a much riskier scenario compared to web applications.
The last four points, in particular, reinforce the importance of rigorous testing for mobile applications before a new version is released.
In light of the complexities inherent in a mobile application environment, development not only requires a zero-friction development and deployment environment, but it also requires an environment in which extensive automated mobile application testing and qualification can occur, all in the same pre-integrated fashion.
Using the power of continuous integration and continuous delivery, you can solve all of these problems, accelerating your ability to deliver quality mobile apps at scale.
How to Always Be Release-Ready
The underlying philosophy of continuous delivery is to always be release-ready. That is, the software is in a state at all times where it is ready to be released, if a business decision was made to do so. This might not be what you want to do for a variety of reasons – that’s fine – but the idea is to make sure your application is as stable as it can be at all times.
The only practical way that applications can be release-ready at all times is to have all of the release processes, from code to production, fully automated and pre-integrated. If the processes have to be manually executed and maintained, the overhead cost and friction make it challenging to maintain a constant release-ready state. The mindset that frequently exists in typical packaged software environments (“Let’s start integration and testing of our application three months before release date”) doesn’t work in the mobile world.
To that end, two concepts are extensively used in a release-ready environment: continuous integration and continuous delivery.
In old-style waterfall development, testing activities take place sequentially as a phase near the end of development and before production release. However, Continuous integration (CI) is a process by which testing activities take place in parallel with the development process, continuously.
With CI, whenever a developer performs a code change, a complete series of tests is initiated to make sure the code change doesn’t break the application. If the tests fail, it is easy to spot the issue and resolve it. Understand that the term “test” doesn’t simply mean basic unit tests: a CI server is able to coordinate a very sophisticated set of tests, gated by previous results (unit tests, integration tests, smoke tests, mobile testing, load-performance testing, security testing, etc.).
The result of leveraging CI is that it leads to higher quality and greater agility.
Continuous delivery (CD) is the natural extension of CI, where the output of a CI cycle is pushed to a testing, staging, pre-production or production environment in a fully-automated fashion. This makes it possible to try the next iteration of the software in a real-life situation or, in the case of an internal deployment to production, to quickly deploy a new version of an application with no IT friction.
Deployment can happen in stages (such as in Blue-Green testing) and can be automatically rolled back if something goes wrong. Given that no friction is involved in pushing a new release to production, deployment can happen frequently, for incremental feature changes.
The obvious consequences of leveraging CD is that it leads to safer deployments, is an excellent discovery/validation process for new features and provides much faster time-to-market.
Incorporating Continuous Delivery into Development
Consider the following best practices in your mobile CD activities:
- Testing Back-End Interactions. By using a middle-tier layer between your mobile app and back-end services, you can automate testing more easily and enable multi-stream development.
- Cross-Device Testing. Use a device cloud service along with emulator-based testing. Test on a representative set of devices and emulators routinely, with more elaborate tests layered afterward.
- Integrating Cross-Platform Testing. Establish milestones that include integration testing across platforms, using Jenkins pipelines to drive identical tests across all clients that might affect back-end interactions.
- Testing the Mobile User Experience. Plan to test the full mobile experience, including navigation, pre-emption, location, orientation and network factors. Expect to move well beyond web app testing experience and tools.
- Beta Test Distribution and Analytics. Use beta test distribution, crash reporting and analytics services to get real data from real users. Use well-proven integrations with Jenkins to gain access to popular services.
- Customizable and Flexible Build Environments. Mobile development and testing toolchains are evolving amazingly quickly. It is important to be able to spin up fresh environments in parallel with your existing, stable environments.
It is clear that mobile is here to stay. As more and more businesses and consumers use mobile applications, the applications will increase in sophistication. To keep up with business demand and be successful in their markets, development teams will have to support the world of mobile development by adapting automated development technologies, processes and team culture.
Mobile application development teams should:
- Explore use of a continuous integration solution – to help develop/stage high quality code – and extend CI practices into application delivery in a process known as continuous delivery. There are many such solutions available today, perhaps the most popular being the open source Jenkins CI server.
- Use cloud services to supplement on-premise infrastructure, as needed, for testing and running builds. Cloud services allow you to instantly scale up or down, as needs dictate, only paying for resources actually used. No more begging for resources or incurring long delays while infrastructure gets ordered, received, provisioned and configured.
Finally, you must automate the testing process, itself – check out automated applications for testing various devices, form factors, operating systems and for the distribution of beta releases. There are a number of tools and services available today for these important – and very tedious – activities. For example, SOASTA’s TouchTest service runs fully-automated, gesture-aware tests to ensure that the all-important user experience remains consistent across application builds, device types and form factors. You can also run tests against software emulators or actual devices, using locally-tethered devices or device clouds (like PerfectoMobile, Keynote, and AppThwack provide), and integrate with leading beta test distribution, A-B testing and analytics services such as TestFlight, HockeyApp and Vessel.
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.