Let’s get something out of the way first: there’s no such thing as Mobile DevOps. In fact, setting the “mobile” part aside, “DevOps” itself is pretty buzzword-y and amorphous. But the philosophies and practices collectively referred to by the term are real, and software development teams are increasingly leveraging them to level-up the quality of what they ship and to improve the way in which their team works.
When we use the term “Mobile DevOps,” what we really mean is, DevOps practices applied to the mobile use case. It’s just normal DevOps, but the particular application to mobile merits a distinction. Because of the unique ecosystem and challenges inherent in mobile app development, teams stand to gain even more from adopting DevOps practices. Through the entire software development lifecycle, and especially towards the release end of the process, DevOps allows mobile teams to better structure, coordinate, and automate many of the moving pieces.
In this piece, we’ll start by recapping some of the core concepts underlying DevOps. Then, we’ll highlight how DevOps can benefit mobile teams in particular, considering the uniquely-mobile challenges it helps teams overcome. We’ll wrap up by sharing some practical tips to help you and your team on the journey towards Mobile DevOps adoption. (Spoiler: CI/CD alone is not enough!)
What is DevOps?
DevOps loosely describes a framework of principles, goals, and practices that together allow teams to build, test, and release technical products more efficiently and reliably. Because it’s an inexact term, there are varying interpretations and implementations, but a few ideas are core under DevOps:
- Reduce silos within teams and across the organization. In particular, bridge gaps between those who manage developer tools (IT, ops), those who build the product (engineers, product managers, designers), those who test the product (QA), and those who release the product and monitor it in the wild (release engineers, customer service).
- Break up long-running projects and make linear processes more parallelized and asynchronous. Favor smaller, more discrete tasks and shorter iterative cycles. This generally aligns with Agile methodology, and is antithetical to more traditional, “waterfall” approaches.
- Empower teams and individuals to handle themselves those tasks they would have previously had to lean on (read: bug!) other people for. This involves equal parts tooling and cultural shift.
- Automate as much as possible. Enough said.
DevOps influences the entire software development lifecycle (SDLC) - in fact, that’s the whole point. Everything is connected in a feedback loop: from planning, to building (the “create” stage), to verification (manual and automated testing), to release. Continuous monitoring provides the entire team feedback on how the application is performing during verification and once it’s out in users’ hands. Based on this feedback, new features and fixes are planned, and the whole cycle repeats.
Teams of all shapes and sizes can derive real value from implementing DevOps practices. Some of the typical benefits you might expect to see:
- Shorter release cycles
- Higher product quality and reliability
- Better human and technical resource utilization
- Increased and easier collaboration
- Improved ability to find and fix bugs
Mobile DevOps: a perfect match
You’ve probably heard this refrain before: mobile development is unique. As a “line” it’s getting a bit trite, but there’s still truth to it, especially when it comes to the release end of the mobile SDLC. As it turns out, many of the challenges that come with mobile’s uniqueness are eased by DevOps practices.
Problem: Mobile releases are slow, and gated
Compared to web and other kinds of deployment, preparing mobile builds and releasing apps is an inherently slower and more gated process. Building binaries is cumbersome, and because the bar for shipping packaged code is much higher, more checks and sign-offs are required all along the way. The app stores impose additional requirements and roadblocks - especially on the Apple side, where the review process layers on waiting time and uncertainty.
Solution
Expanded automation under DevOps can help a lot here. One of the obvious targets is automation to streamline the build process. But teams who are able to implement more holistic, end-to-end automation can not only speed up specific steps in the process, but also reduce or eliminate the waiting periods and handoff friction between steps. And, to the extent that successful automation can shrink overall release timelines, teams are able to release more frequently, which can mitigate the macro impact of slowness or hiccups in any one particular release.
Often non-mobile teams aren’t familiar or comfortable with mobile’s constraints, and this compounds any friction that already exists. DevOps’ call for more visibility and shared responsibility across roles and teams helps alleviate this. When ops, backend teams, and other stakeholders further afield are more aware, they become better allies and everything gets easier.
Problem: Mobile testing and monitoring are made difficult by fragmentation
Testing and monitoring are more difficult for mobile because of fragmentation in the mobile ecosystem. There are myriad platforms and devices to account for, each with different capabilities and screen sizes, and in the wild they’re subject to a variety of operating conditions (think poor or non-existent cell service). Also, teams have to deal with a long tail of different operating system versions and app versions. The latter is especially frustrating. Although many users have automatic updates turned on these days, a non-negligible portion of users don’t, meaning teams can’t be certain when new updates or important hotfixes will be adopted by all.
Solution
Mobile DevOps makes better, more comprehensive testing easier with a combination of automation, transparency across domains, and agency for cross-functional players. Automated testing should already be a no-brainer, but it’s especially powerful when used to extend the reach of testing suites across many combinations of device type, operating system, operating environment, etc. Where automated testing reaches its limits and manual testing is required, reducing the distance between the people testing (QA) and the people building (engineering/product/design) by making the process more transparent can improve overall testing quality. Often, non-QA team members are empowered to participate in testing. You may even see the gap is eliminated entirely by removing the dedicated QA function altogether in favor of “self-QA” by product teams.
Monitoring is made easier with dashboards and other shared spaces for the entire organization to easily keep track of all app versions in the wild. In the spirit of Mobile DevOps’ breaking down of silos, this info should be collected from a variety of sources - stability and crash data, user reviews and app store data, project management boards, build systems - and then digested and surfaced with a diverse audience in mind: from customer service to ops to engineering to C-level and beyond.
Problem: Mobile app users are less forgiving (and their needs are harder to meet)
While most users will casually refresh the page or leave and return later when they run into issues on a website, bugs and crashes on mobile are much more disruptive. Broken functionality on mobile very often leads to users leaving bad reviews and uninstalling the app entirely. And because responding to complaints and fixing issues is relatively slow (see above), the stakes are even higher.
Solution
The Mobile DevOps solution here is an amalgam of pieces of the previous two solutions. Fickle mobile app users become less of a problem when you ship them fewer bugs (better testing), when you’re able to track and respond to the issues they do experience (better monitoring), and when you can ship them new features and bug fixes as regularly and as efficiently as possible (smoother, quicker releases). With the entire cross-functional organization aligned and with extensive automation in place, your team is better prepared to meet the demanding standards of your app users.
Implementing Mobile DevOps
Hopefully you now have a clearer understanding of what Mobile DevOps entails, and a general sense for some of the concrete practices behind the term. But now that you, your team, and the wider organization have decided to adopt, or level-up, your DevOps culture, what do you do next? To make things more actionable, we’ll highlight some of the big pieces you should be sure to get in place.
There’s many facets to successful Mobile DevOps, and areas of focus may vary based on your company and product, but these four items make up a pretty universal foundation:
- Automate builds and tests
- Set up and maintain a lean CI/CD pipeline
- Establish a considered, repeatable release process
- Create shared spaces around mobile, and mobile releases
1. Automate builds and tests
This low-hanging fruit is often the first step teams take on their Mobile DevOps journey. Builds especially are very easily automated these days, and there are various out-of-the-box tools that can help out here.
By setting up continuous integration (CI), teams can automatically build and run tests on any code changes pushed to their app’s codebase. Static code analysis and other checks can be performed as part of CI, and with visual dashboards and integrations with notification platforms, engineers and the wider team can get immediate feedback on code quality and build status.
When it comes to automated testing, each type plays a part in combating the overall challenges of testing for mobile, so implementing a mix is advisable. A recap of the main options and what to watch out for with each:
- Unit tests: Unit tests check that a small unit of code - for example, a single method - works as expected in isolation. These are generally the easiest tests to write and automate, so apply liberally.
- Integration tests: Integration tests ensure that multiple units of code work together as expected, and they’re used to evaluate more complex functionality and business logic. Integration tests often require some backing data from APIs or databases. Where possible, use stubs or mocks instead of live data, to reduce flakiness and improve repeatability.
- UI tests: As the name suggests, UI testing focuses on the user interface, ensuring that it appears and behaves as expected. One of its simplest forms is a kind of visual unit testing. Commonly referred to as snapshot testing, this practice compares specific, discrete UI elements against “known good” versions and fails tests if any unexpected visual differences are found. Other UI testing involves complex, compound flows that require interacting with the app the same way a user would. For this, teams need testing environments with various device emulators or even physical devices - tools like Appium, BrowserStack, and Mobot can help here.
- End-to-end tests: End-to-end (E2E) tests capture entire user flows and ensure that complex acceptance criteria are met, throughout the stack. They’re the most difficult tests to implement and maintain, and the slowest to execute. Given that slowness, they generally shouldn’t be executed on every commit or pull request; instead, they should be run at semi-regular intervals and at strategic points during the development cycle, e.g. at key checkpoints leading up to releases. End-to-end tests provide more robust coverage, and they can be leveraged for testing apps on different devices and under varying network conditions.
By automating builds and implementing a mix of automated testing against your app, you take a big step down the mobile DevOps automation path and better prepare your team for the inherent challenges of shipping stable mobile products.
2. Set up and maintain a lean CI/CD pipeline
There’s more to do after building and testing your app, which means there’s more to automate! Once that earlier part of the pipeline is up and running, add more of the CD piece by automating delivery, both to staging environments and to production. Besides eliminating individual manual tasks along the way, chaining together this pipeline of automations reduces the waiting time and handoff inefficiencies that exist between the individual tasks. Every mobile team’s favorite open source tool, fastlane, can be very helpful here.
Setting up regular, automated distribution to staging or beta environments is especially important in the DevOps context. Getting versions of your app into the hands of other teams and testers more quickly, and more regularly, helps to eliminate silos and solidifies the feedback part of the DevOps lifecycle. Leverage TestFlight, Google Play test tracks, or third party distribution platforms for this.
When it comes to CI/CD, stay lean and focus on core principles: creating, testing, and distributing builds. There’s a common misconception that CI/CD is DevOps panacea. Not only does it not cover all the DevOps bases, it can actually create more silos and diminish visibility. More on this in a future piece!
3. Establish a considered, repeatable release process
Set aside time and resources for putting in place, and maintaining, a structured and deliberate release process. In doing so, be sure to solicit ideas and feedback from all teams and stakeholders involved (silo-busting!). In certain organizations this is something that can happen quite informally and organically; in others, you might consider setting up specific, interdisciplinary working groups. This should be an ongoing exercise whereby you regularly revisit tools and practices to ensure they’re meeting your team’s needs, and adapting to changes in the organization.
Avoid falling into the trap of ‘well, this is just how we do things’ – handling the release process as an afterthought. Usually this happens gradually, without teams knowing: small teams start out releasing by the seat of their pants, and as they grow they never pause to establish a more structured, robust system. It can be difficult to escape that hole, because releases are an unsexy problem area that’s constantly relegated to the bottom of a team’s list of priorities - or just overlooked altogether.
From a DevOps perspective, one of the most relevant aspects of the release process has to do with the fundamental model teams choose to follow: ‘feature-based’ or ‘release trains’. While both models have pros and cons that vary by company, team, and app specifics, release trains are arguably favored under DevOps. Whereas feature-based releases tend to be slower and more waterfall-y, release trains lend themselves to discretized work and faster iterative loops. A strict and predictable release train is easy to rally entire teams and organizations around, and there’s less wrangling or bureaucracy when it comes to what gets released when.
4. Create shared spaces around mobile, and mobile releases
Relative to how many moving pieces and different roles are involved, the typical surface area over which all things mobile are made visible is quite small, and often very fragmented. Putting effort into creating shared spaces where mobile teams and the wider organization can understand the work being put into, and the successes of, mobile releases can go a long way towards breaking down silos — and ultimately foster a greater sense of collective ownership.
These collaborative spaces can take many forms. Some ideas:
- Live dashboards showing release metrics like stability and adoption
- Feeds of user reviews from the app stores. Even better if you surface them somewhere people can comment on specific reviews, e.g. to triage bugs
- Wikis or documentation outlining the mobile release process, with particular emphasis on the dependencies and responsibilities that cut across different teams
The case for Mobile DevOps: not easy, but worth it
The shift towards DevOps can be a tough adjustment for some organizations. Traditionally, there’s quite a stark - and, often, deliberate - wall between teams, particularly between product and operations teams. DevOps challenges that on a fundamental level, by breaking down silos and making all parts of the development cycle a shared responsibility. The tools and practices described in this piece are helpful levers teams can use to move in the right direction, but everyone involved must buy into the philosophies behind DevOps in order to realize its full benefits. It isn’t an off-the-shelf process you can just flip a switch on, or a fancy term to be thrown into a job title. DevOps represents a fundamental change in the way people work together and how information is shared across a team.
Still, all the hard work and cultural change is worth it, especially in the mobile context. In adopting DevOps practices, mobile teams are able to ship higher quality apps more quickly and with less friction. Start small, with some of the discrete DevOps solutions we’ve highlighted here, and gradually expand your Mobile DevOps practice from there.
