The Four Pillars of Mobile DevOps Strategy
The Four Pillars of Mobile DevOps Strategy
These four pillars are essential to upholding your mobile DevOps strategy.
Join the DZone community and get the full member experience.Join For Free
Recently, mobile DevOps has been a topic that pops up throughout organizations as people outside of mobile development are increasingly aware of the differences between mobile and traditional DevOps. As the need for adoption of processes specific to mobile development grows, technology leadership is looking for goals and metrics that make sense. Even though these will obviously vary from company to company or even from project to project, we can characterize four key components that will deliver results.
You may also enjoy: The Difference Between a DevOps and a Mobile DevOps Lifecycle
The first — and perhaps most obvious — component to a mature mobile DevOps strategy is the drive to maximize the value delivered. Even though mobile developers face many challenges compared to their colleagues in more traditional software engineering, they actually have a head-start here.
In almost no other field will the feedback loop be more direct and more obvious than it is for mobile. Part of this is due to a range of relatively sophisticated in-app analytics solutions, but when developing mobile applications for external use, end-user feedback often comes rapidly (and sometimes painfully) through the mechanics developed by Apple’s App Store and Google Play.
Tightly integrating these analytics solutions and feedback loops with your other mobile DevOps processes will ensure that the value of each release isn’t just measured, but also directly informs and influences your complete mobile DevOps lifecycle.
Success on mobile is about speed. Continuously enriching applications with fixes, features and functionalities isn’t just a "nice to have" but a must, as you operate within shorter and shorter windows of business opportunity. Continuous integration and testing enables your mobile teams to thrive in an environment that — in many cases — follows the "quick or dead" imperative.
Even though the culture of fear-of-failure and change-avoidance is a rarity in mobile, the more security your mobile DevOps process provides, the higher the confidence level of product and development-teams and the higher the release velocity you’ll achieve. Continuous integration and testing should provide this security, either through traditional on-prem or cloud solutions, or a mobile-specific CI.
There isn’t necessarily a rule of thumb as to what speed you’re aiming for here. Recent research by Peking University even found that increased velocity negatively impacted app store ratings in certain cases. Those cases were limited to apps that were already on a downward quality trajectory, though, and in an increasingly crowded competitive landscape, that’s not a trajectory you can afford to be on.
Quality is a challenging subject for mobile developers. Apps don’t just end up on different OS versions, they also make their way to countless different devices, often sporting unique form factors and hardware peculiarities which make "no crashes" an unattainable goal. Instead, mobile DevOps strategy focuses on rigorous testing and rapid detection to minimize crashes and their impact.
One thing to be mindful of is the impulse to focus on emulation over device testing as it’s cheaper, faster, and — arguably — easier. It’s usually all of these things, but it also largely ignores the actual production environment your application will end up in: the physical device, other installed software, network conditions and more.
Device farms increasingly allow for automated testing on physical devices and — even though 100 percent coverage is an impossibility — knowledge of device parity (which devices showcase similar characteristics) allows for best-effort coverage of real-world usage conditions. Automated testing on emulators, automated deployment, testing on device farms, and optionally even automated deployment to human testers all ensure that your mobile releases meet your quality standards and — more importantly — the expectations of your end-users.
Mobile developers are expensive. With demand vastly outstripping supply for mobile engineers, maximizing efficiency through mobile DevOps is often a necessity simply to achieve desired output levels with the resources available. In all cases, it frees up time for quality innovation and coding.
Efficient mobile teams work through integrated building tools, testing, deployment solutions, monitoring and excellent communication. The right tooling and — above all — trust in the tooling allows for extensive automation of processes: From source code management to build automation, testing, and deployment, all the way up to app performance monitoring and app analytics in production. mobile DevOps tooling allows for automatic processes triggered by the output of all these services and processes, increasingly unburdening development and ops teams from tasks that are boring, difficult or error-prone.
Collectively, these four pillars are a great kick-off point for formulating your own mobile DevOps strategy. If you’re in tech leadership, I’d be remiss to not point one very important first step, though: Talk to your mobile developers. More so than almost any other software engineering discipline, mobile development necessitates a lot of "DevOps-adjacent" processes. Your mobile teams are guaranteed to have some awareness of the requirements and should be an integral part of formulating a fully-fledged mobile DevOps Strategy.
Opinions expressed by DZone contributors are their own.