Over the last few years the enterprise world has taken up the mantra of DevOps - small, versioned, automated, tested, metered, change! At the same time, the market as a whole is changing from large scale enterprise apps and complex web applications, to much more focused capabilities delivered thru very personal mobile devices. These two changes are coming together due to the challenges that mobile development brings to the enterprise. We have accepted the BYOD (bring your own device) movement, and it has brought us a plethora of target platforms for our mobile applications. Our customers have also moved from the monolithic days of the single desktop environment, or the simplicity of a few targeted browsers, to10's of operating platforms and 100s of screens resolutions. We also have user expectations which are driving us away from the safety of mobile web, to hybrid and native applications.
While MEAPs can solve many of the challenges of building these new hybrid and native applications, they do not solve the problems of testing these applications. We can use third parties to do our testing, or assume that testing against one or two devices, is enough; however, when your brand is literally held in your customers' hands, do you feel that is enough? Do you believe that you can accurately repeat the build and test process for each of the platforms? These are the challenges that DevOps addresses.
DevOps is not a management driven initiative to reduce costs and improve quality (though it does address this). DevOps is not a developer centric view of the world, where operations no longer plays a role in provisioning environments (though it does mean that operations can focus even more on meeting production SLAs while Development can focus on providing the business new function, more quickly).
In the context of Mobile, DevOps should be focused on a few, key pain points. The next few paragraphs will address how I believe DevOps addresses those pain points for mobile. If you are unclear on the definition of DevOps in the enterprise, take a few minutes to read the following blog from Steve Abrams.
As mentioned above, one of the big challenges for Enterprise Mobile Application development is the potential permutations of devices, screen sizes, carries, and operating systems you must support. While this is certainly a challenge for application design and development, it also drives complexity into your build and test processes. The added complexity of adding in certificate provisioning, provides additional opportunity for your build to pick up the wrong versions of code, configuration, and services thereby increasing the risk of problems in test and production. However, if you can provide your developers with production-like automatically provisioned environments, capture the build and configuration scripts used to create them, and use those same scripts for developer, test, and production builds, you not only reduce the risk of incorrectly building and deploying the app, you increase the test coverage because you are not only testing the function at each stage, you are testing the deployment too.
The second challenge that this permutation causes, is how do you test all of these environments. The short answer is, you don’t, you can’t, it is cost prohibitive. However, that doesn’t mean that you shouldn’t try to provide the most effective testing across as many configurations that are necessary. When I think of testing mobile apps, there are three potential ways of testing (and they are not mutually exclusive): 1) Simulators, 2) Emulators, and 3) Devices. A complete testing strategy will leverage each of these methods of testing, and automation of testing is critical In DevOps we will automate this testing as much as possible, and we version those tests, so that we know exactly what test went with what version of the software. This practice let’s us not only confirm functionality with every build, but also allows us to reduce the risk of regression when new features are added, while confirming problems on versions of the app that are already out in the field. As a developer this means I can focus on quickly adding new function, and easily understanding it’s impact on my app. Again, reducing the risk that new function will break existing capabilities when my app goes live.
There are two more areas of DevOps that I believe are critical for Mobile App Development within the enterprise: governance of app development and app store distribution, and user feedback. But these topics are for an upcoming blog entry. Tell us what you think in the comments below. Are you experiencing these challenges? How are you addressing them?