It’s Time That Mobile Got Its Own DevOps Department
Competition and demand in the mobile space will soon outpace developers' ability to keep up without dedicated teams, tools, and practices.
Join the DZone community and get the full member experience.
Join For FreeEver since the first mobile apps emerged with the release of the iPhone, early mobile engineers have had to borrow best practices — not to mention talent and technology — from their companies’ existing DevOps teams.
DevOps leaders became mobile leaders. Software engineers started building for mobile. And everyone ‘faked it till they made it’ until realizing that somewhere along the way, their companies’ mobile revenue had begun eclipsing revenue generated by other channels.
And just as quickly as companies realized mobile’s importance, they realized that bringing mobile apps to life is much different than launching traditional software and web apps.
Despite mobile’s profound nuances, however, it’s been almost taboo to suggest that the DevOps teams that have worked so hard to establish mobile within their organizations should finally be complemented by the introduction of dedicated Mobile DevOps departments.
In fact, a recent survey of more than 1,300 mobile practitioners found that just 8% of mobile companies have a dedicated Mobile DevOps team. Unsurprisingly, another 46% said that the biggest challenge their organizations face when it comes to Mobile DevOps is a lack of mobile-specific expertise, tools, and resources.
As competition and demand in the mobile space continue increasing at a rate that will soon outpace mobile developers’ ability to keep up without practices of their own, mobile organizations need to take off the training wheels and create their own path within their organizations — and industry-wide.
Here’s a look at three nuances responsible for mobile outgrowing the loving embrace of the traditional DevOps practices that have gotten it this far — and why mobile now must find its own way.
Mobile apps are built in a different environment than the ones that most developers are used to.
Whereas seasoned developers have spent the majority of their careers operating within integrated development environments (IDEs) such as VS Code, Mobile DevOps is dependent on two entirely new environments: Xcode and Android Studio.
Not only do developers have less experience in these environments, but the IDEs themselves have fewer resources, guides, and tools surrounding them than what developers are used to in traditional DevOps—simply because they’ve only been around for a fraction of the time that traditional IDEs have.
This makes it more difficult for developers to identify and debug problems when they happen, as in web and other environments, these problems occur in the visual format they’re used to, making them easier to pinpoint and troubleshoot.
Outside of the challenges the Mobile DevOps environment presents internally, across the industry as a whole, its nuances need to be reflected in industry standards and benchmarks. Google’s DevOps Research and Assessment (DORA), for instance, has been a navigational beacon for software developers to optimize their performance. But until the introduction of Bitrise’s Mobile DevOps Assessment (MODAS) earlier this year, mobile engineers didn’t have their own benchmarks to understand what is considered above average, average, and poor performance in an evolving ecosystem.
Apple and Google act as gatekeepers that change operating system guidelines and tooling one-sided.
Operating system updates within the Apple and Google mobile app duopoly are constant, and each one inevitably requires teams to update their apps to account for new conditions, broken functionality, and other byproducts of the updates.
App stores additionally dictate apps' visibility to users following a ranking system that isn't just based on user ratings but on metrics such as app release frequency and cadence.
These requirements don’t exist in traditional DevOps and have left mobile engineers with a trial-and-error-based approach to determining how quickly and how often their companies’ apps need updating in order to not only get approval to be featured in app marketplaces but be competitive once they get there.
As consumers entrust more and more of their everyday activities to the mobile apps that they find in these marketplaces, this trial-and-error approach needs to mature into established skills and best practices for achieving mobile success.
Mobile companies have to support every previous version of their app for every available device forever.
In addition to keeping up with mobile operating systems themselves, mobile teams now have more than 20 different Apple devices to keep up with and hundreds more for Android. Since it’s possible that app users could be using any one of these devices, developers have to update and maintain multiple different versions of their apps to accommodate them.
Operating at this scale leaves little room for errors and delays caused by DevOps practices that aren’t 100% optimized for the channel they’re developing for. It also requires development teams that have an intimate understanding of this "device fragmentation" and the resulting emergence of device farms, from which mobile teams can view and manage different versions of their apps on any device that ever existed.
Yes, depending on traditional DevOps teams to moonlight as mobile teams have gotten mobile companies to where they are now. But until they fully understand how Mobile DevOps is different and where the opportunities lie for them to improve their mobile strategies with mobile engineering experts, mobile-specific technologies, and mobile-specific best practices, they’ll see their success start to plateau while others move forward.
Published at DZone with permission of Barnabas Birmacher. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments