by Leigh Williamson, Sanjeev Sharma | Published May 13, 2014
Over the past five years many industries scrambled to adapt to a massive shift in the behavior of business applications users, as millions across the globe adopted mobile devices as their primary means of accessing the internet. This crucial shift in user behavior is strong motivation for enterprises to develop mobile channels for existing business applications, and to plan for new kinds of applications that can use the unique characteristics of mobile devices. As with all major evolutions in the IT industry, the first years of this shift saw frantic activity to meet demand and create market presence without considering more strategic issues such as application development costs, maintainability, quality, and security. As the mobile application market matures, and the initial rush to market settles, it is now possible to bring these more comprehensive software development issues into focus.
In this article, we discuss the challenges of integrating mobile apps in the enterprise and present 10 best practices for mobile DevOps. We start with an overview of DevOps and explain some of the specific challenges — and the necessity — of integrating mobile enterprise apps in a DevOps shop. Next, we present 10 best practices for implementing DevOps in a workflow that brings together continuous integration, application testing and monitoring, and mobile app delivery.
DevOps is not a technique or a process, but an approach to enabling seamless application delivery from inception to production. Before the emergence of DevOps, it was typical for enterprise organizations to maintain separate development and operations teams. The lack of communication and collaboration between teams was in many ways a challenge to growth and innovation in the enterprise. The separation of development and operations was vexing for enterprises that adopted agile development, as using agile methodologies increased the number of new application builds to develop, test, and deploy by several orders of magnitude. Instead of delivering a new build to the operations team every few months, developers were able to produce builds every few hours and deliver release candidates at much higher frequencies.
The DevOps movement started with dev and ops teams who came together to more effectively address the challenges of continuous application delivery. An initial goal was to “shift left” the responsibilities of operations, involving ops much earlier in the software delivery lifecycle. Next, developers were encouraged to code applications with operational concerns in mind from the beginning. In effect, DevOps coordinates the interests and knowledge sets of developers and operations managers, by using the principles of lean development to make the process of continuous integration and continuous delivery more efficient.
IBM takes a holistic view of DevOps, defining it as enterprise capability for continuous software delivery that enables clients to seize market opportunities and reduce time to customer feedback.
The key term in this definition is continuous delivery. Continuous delivery means deploying software and the environment on which it runs, automatically and on demand, at any stage of the software delivery lifecycle. In continuous delivery, you might deploy anything — from simple configuration changes, to incremental code changes, to database schema changes, to changes to the environment, or to the whole stack.
DevOps employs the same basic principles whether you are coding enterprise web apps or mobile apps. Include your mobile development team while you adopt DevOps for the enterprise, even if the mobile team is a small part of your enterprise or follows a different software development process. This is especially true if you are developing mobile apps as a front end to existing enterprise applications and services. It is also true regardless of whether the app is consumer-facing or intended for internal use.
Mobile apps that interact directly with enterprise applications and services need to be first-class citizens in the DevOps lifecycle. As new features are added to the enterprise application or service, the teams can seamlessly integrate them into the mobile app.
While the basic principles of DevOps are the same for enterprise and mobile apps, mobile apps do present specific challenges to DevOps. These challenges include:
Mobile apps do not have a single environmental target. Most mobile apps target multiple devices, which means dealing with various technical specs, OS versions, and form factors. Android is well known for being fragmented, as each device vendor has forked the operating system for its own devices (examples include Android for Nexus, Android for Kindle Fire, and Android for Nook). Newer entrants like BlackBerry 10, Windows® Phone 8, Ubuntu, and Firefox are now further fragmenting the Android market. Likewise, iOS, which was once very standard, today has multiple variants. An iOS application needs to support different versions of iOS; the iPhone 4S and below form factor; the iPhone 5 form factor; and the iPad and iPad mini form factors.
Mobile apps as an enterprise front end
Mobile apps, especially enterprise business-to-consumer (B2C) or business-to-employee (B2E) mobile apps, typically have little business logic on the mobile device itself. Instead, a B2C or B2E mobile app serves as a front end to one or more enterprise applications already in use by the company, such as transaction processing systems, employee HR systems, or customer acquisition systems. Figure 1 highlights such an app with limited business logic in the app itself.
The LinkedIn mobile app is really a front end to the backend LinkedIn Platform, which contains LinkedIn’s Profile, Connections, and Groups applications or services. The mobile app, which is delivered to multiple platforms as a native or hybrid app, needs to be developed and delivered in conjunction with the backend LinkedIn Platform services. For DevOps the challenge is to think holistically of all of the applications in the enterprise and coordinate their build and release processes and cycles.
Continuous integration and continuous delivery
Because of the strong business motivation to deliver mobile applications to market quickly, mobile development projects typically have extremely aggressive time lines. An inception-to-delivery period of a few months, or even weeks, is common. The pressure to deliver mobile apps quickly results in the adoption of agile development methods for most successful mobile projects.
Continuous integration and continuous delivery are important elements of nearly all agile projects. Application changes delivered by developers need to be processed immediately for all of the targeted mobile operating systems. If the mobile application is a hybrid or native implementation, several different builds of the application need to be triggered each time that a change set for the application is delivered by a developer. The build setup and configuration for each supported mobile environment is different from the others. You are most likely to need a small farm of build servers to be provisioned and available to handle these multiple operating system builds.
The app store
In most cases a mobile app cannot be directly deployed to a device. It has to go through an app store. Apple introduced this app distribution model and locked its devices to prevent direct installation of apps by app developers or vendors. Device manufacturers like RIM have followed suit.
The app store adds an additional asynchronous step to the deployment process because developers are unable to deploy app updates on demand. Even for critical bug fixes, new app versions go through an app store submission and review process. Continuous delivery becomes “submit and wait.”
‘Pull’ not ‘push’ deployment
Most traditional deployment operates on a “push” model whereby operations can push out a new version of an application on demand, be it a web application or any other server-based application. The process for updating mobile apps is a “pull” process, however, where in most cases users must choose to update their apps for themselves. Mobile application developers have little control over which version of the app an established user keeps on his or her device. From a DevOps perspective, this means that the deployed back-end services that an app interacts with must provide continuous support for previous releases of the mobile app.
For consumer apps, failure is not an option
Nothing is more hurtful to a brand than an app with a one-star rating, particularly when that rating is broadcasted through the medium of an app store. Unsatisfied users of consumer mobile apps can become public and visible quickly, regardless of whether the app is purchased or free. While complaints about issues with a website are communicated to a technical support desk, complaints about mobile apps are broadcasted via the app store for everyone to see. Mobile apps must undergo extensive functional, usability, and performance testing to ensure their quality.
Based on the challenges specific to mobile apps, we recommend 10 best practices of DevOps for mobile apps. These practices fall into three broad categories of capabilities, namely:
The goal is to use the 10 best practices to create a delivery pipeline that enables these three capabilities, while simultaneously addressing challenges specific to mobile apps.
A DevOps delivery pipeline implements the technical side of DevOps, but it is also important to address the human and cultural dimensions of the DevOps movement. The best practices in this section are meant to ensure that enterprises include mobile development and QA teams as first-class citizens in their DevOps community. A holistic DevOps philosophy must account for the needs and concerns of mobile application development teams who work in tandem with teams who develop enterprise web applications and services.
Ensure end-to-end traceability across all assets
The value of traceability across all development and QA assets is no longer a subject of debate. A mobile app development team must ensure end-to-end traceability across all development assets — such as code, configurations, scripts, infrastructure as code, test scripts, design documents. It is also imperative that traceability is not limited to mobile development assets; it must extend to enterprise applications and services that mobile apps integrate with, connect to, or access.
Practice continuous integration
Agile development practices preach continuous integration, which means running frequent builds and continuously integrating new code with code previously developed by other teams — both mobile and enterprise. Continuous integration ensures that the code that is delivered by one development team works with code and modules that are delivered by other development teams. Integration is typically performed continuously for mobile apps. It should also be performed periodically with the non-mobile server-side components that comprise the backend that is accessed by the mobile app under development.
For mobile apps, the development teams share central build and integration servers for the mobile app code that serves all mobile platforms that are targeted. Automating the build and development process ensures fast and reliable continuous integration builds that are performed on central build servers, or server farms, for all supported platforms.
Maintain separate build and integration areas for each native mobile OS SDK version supported
Fragmentation in the mobile device space extends beyond just the four major mobile operating systems of iOS, Android, Blackberry, and Windows Phone; each of these operating systems is also internally fragmented. Apple forked its own iOS to support the iPad. Android has variants for nearly every device. RIM’s BlackBerry 10 is a brand new operating system with limited relationship to the legacy BlackBerry OS. Windows Phone 8 is a major makeover of previous incarnations of the Windows Phone. Several new mobile platforms are coming up too, including ones from Ubuntu and Firefox. As a result, mobile app developers must write multiple app variants to support each targeted platform and its variants, even if they are targeting just one platform. Every mobile app requires multiple versions of its SDK.
To ensure separation of code and the specific capabilities of each targeted platform, developers must maintain separate “streams” of development for each platform-specific version of a mobile app. This division requires maintaining separate build and integration areas for each platform targeted. If an Android app, developers would need to have separate streams for Kindle Fire, Nook HD, Nexus, and other operating systems.
Use automated build and deploy scripts
Mobile developers are accustomed to using an IDE to manually run builds. They often run builds manually and in some cases for different platforms they are targeting. As the complexity and number of builds increases, developers can set up automated builds, by using scripts to run builds as needed on separate build servers. Manage build scripts and assign versions just like code, ensuring that each build can be reproduced at any time and by any team member.
Test each build thoroughly with as much automation as possible, on simulated and physical devices
Test automation is an area where mobile app development lagged behind enterprise apps. Most mobile developers test extensively on a simulator but not on physical devices. Even testing on a simulator is mostly manual. Given the speed of development and the inherently agile nature of mobile development, automated functional regression testing is the only real way to ensure quality. Given the myriad of platforms and form factors that are supported, it is not possible to manually do enough testing. Furthermore, for enterprise apps, whether they be for customer or employees, low quality is not acceptable.
Test all apps with automated testing tools, on simulators that are provided by the SDKs, and on all actual physical devices supported.
Virtualize and simulate backend services that are not available during mobile app testing
Mobile apps follow a rapid development process, which can result in many more releases when compared to backend enterprise applications and services. Such rapid development can keep mobile apps technically ahead of the curve of enterprise applications, meaning that they have newer features that aren’t yet supported by backend enterprise applications and services. Even when backend services are available, they might cost money or resources to test against. For example, SaaS services usually have a pay-per-use cost, even for testing. Similarly, System z (mainframe)-hosted services cost MIPS. Development teams can solve this problem by virtualizing (simulating) backend services. The entire ecosystem of applications, services, and data sources that the mobile app needs to interact with can be made available as virtual instances, simulating the behavior of the actual capabilities the mobile app needs to interact with. This arrangement allows for rapid testing of the mobile app and its interactions. It also saves hardware resources that would be needed to run actual instances of these services and applications.
Monitor the performance of deployed mobile apps and backend services
Mobile app developers face no bigger challenge than an app that performs well in the test environment but fails in the wild. Unreliable network conditions, low memory, low power, and data loss are some underlying causes of poor mobile application performance. Not all of these conditions can be predicted and tested in a lab, so it is imperative that developers enable continuous performance monitoring as apps are used. Such monitoring can be done either in the app or on the server-end of the application stack that the app interacts with.
The ultimate performance failure is when a mobile app stops running while in a user’s hands out in the field. Adding logic to the app that captures “must gather” context information in the case of failure, such as location data and device characteristics, provides the developer with sufficient data to find the root cause of the failure and correct it. Embedded crash capture and analysis logic is an essential component of mobile apps.
Employ centralized governance for mobile provisioning profiles, certificates, and API keys
Whether to submit an app to an app store or to use an API provided by an internal or external application, a developer or corporation identifies the authenticity and ownership of an app via a vendor-issued provisioning or profile key. These keys serve as the authorization pass to the store or API. Typically, individual developers get their own keys that they use for development purposes. But when the final app is released, remove all these personal keys and replace them with the official corporate keys. Protect corporate keys and profiles and only use them for official app releases. Mobile governance processes must be well-defined and controlled. Above all, restrict access to corporate keys. Authorization is both a security and a privacy issue that requires strict governance.
Use a virtual app store to test device deployment
A mobile app can only be provisioned to a mobile device via a vendor’s app store. Usually the app goes through a manual approval process before it gets into the app store. Once it’s in the store, a user needs to “purchase” the app, which is then pushed to his device. To test this entire process, development teams can use a “private development app store.” These virtual app stores (see Related topics) simulate the behavior of a real app store, enabling developers to effectively test the process of submitting an app and provisioning it to a device.
Convert user feedback into enhancement requests and user stories
Mobile apps have a unique feedback mechanism via app stores that allow users to rate and provide written feedback about them. A well-liked app is likely to receive a four- or five-star rating. A less popular app usually receives a one- or two-star rating, possibly accompanied by negative feedback. The feedback loop for mobile apps is not available as a formal centralized mechanism for any other platform. Developers typically find out about problems with desktop apps only if a user calls tech support or leaves a comment on a forum that is monitored by the developers. Mobile development teams should closely monitor app store feedback and ratings and incorporate the feedback into future user stories, enhancements, and software improvements. Making the most of this valuable feedback is imperative to continuously improving mobile apps.
There is no such thing as a separate DevOps for mobile apps. DevOps is an approach that works for all applications and components — from front-end mobile apps, to middleware, to backend server components and data stores. Apply the practices and principles of DevOps across all dev and ops teams in the enterprise to enable continuous delivery of all of these components.
Mobile apps do have specific needs and challenges that must be addressed. Our 10 best practices of DevOps for mobile apps address these mobile-specific needs. The goal of these best practices is to bring mobile app development, quality assurance, and operational practices in line with standard enterprise applications. Adopting these best practices allows enterprises to adopt DevOps across their mobile development teams, deliver higher-quality mobile apps, and enable continuous improvement and innovation.
May 8, 2019
Back to top