Skip to content

The DevOps approach has produced a variety of principles that are constantly evolving and new tools will be adopted in growing numbers. Tools required to develop and test against the production-like environment, deployment is done with a repeatable and reliable process, and monitoring and constant validation of the process flow are those principles that vary depending on organization’s scope and level of Mobile DevOps adoption. As there are plenty of Mobile DevOps tools and all have a different use case and sometimes can be overlapping each other in the overall Mobile DevOps process, we’ll take a look at different phases of the process and what tools are used in each one of them.


Today’s mobile app developers and organizations behind those are increasingly investing in monitoring systems that can capture production, development, and bunch of other metrics all in real time. This growing trend is great, but if monitoring is done only for specific silos of the overall flow, results may not expose how to optimize the most important resource hogs and therefore monitoring only produces imperfect results. Get your own DevOps manifesto to learn steps and other tips for an agile mobile dev and testing cycle.

There has been lots of discussion about ‘shift-left’ concept where operations focus more on earlier phases of the delivery process and entire production lifecycle. Especially in mobile app testing, this approach and goals are highly useful as the app should be always tested against the real environment – not ‘close-enough’ to a production environment, but actually using the production environment, which in case of Mobile DevOps would mean real physical devices. In addition, it would easily expose issues in earlier phases of the development and issues would be more cost-efficient and easier to fix.

Whereas testing has been traditionally seen as one of the final steps of the process, it is nowadays in the middle of the process, and right after each build. This way the agility of the development and testing isn’t compromised and more data is acquired after each test cycle. This test data with all possible details can significantly help development to fix issues and create more robust apps.

In general, there are 7 widely accepted and used steps in the Mobile DevOps process flow.

Screen Shot 2016-05-30 at 8.51.34 PM

7 Process Steps with Mobile DevOps Tools

Instead of the traditional 4 step process – plan, develop & test, deploy and operate – there are actually more flavors in the process that should be highlighted. Especially when it comes to considering what tools are used, how those fit together and enable seamless tool flow from planning to production. Automation is a critical part of the flow and enables the process to be highly iterative, repeatable, and robust. Automation is actually an enabler for continuous everything, in each step of the process.


First and foremost, code development, code reviews and anything to do with actual development are closely related to continuous integration. The agile approach made continuous integration very popular as it enhanced the way developers work, collaborate and integrate their doings together, in a natural way. The continuous integration with regular daily routines produce lots of data about the mobile application, regressions and compatibility of each developer’s contribution, and discovering issues at early stage exposes integration flaws, incompatibility of developers’ commits, and makes better time consumption and schedule estimating easier and more accurate.


Building application is an everyday job. In Mobile DevOps, organizations use variety of version control, source code management (SCM), different practices for merging code and notifying everyone about the build status.

There are generally few different branching strategies when it comes engineering team to work as part of the Mobile DevOps approach:

  • No branching. Teams work only from the main source tree. This kind of case is typical for smaller teams that do not need isolation for development, releases and builds.
  • Branching for release. For example, the development team can create branches to support an ongoing release. In this scenario, the team creates a branch before release to stabilize the release and then merges changes from the release branch back into the main source tree after the application is deployed.
  • Branching for maintenance. This is not so typical case but development can create a branch to maintain some older application version. Branch is created to support the maintenance of a specific version and current development and regressions are not jeopardized. Sometimes it’s just a quick fix for certain user-base that are not using the latest versions.
  • Branching for features. Engineering team can also create a branch based on a certain feature set. This is quite typical when certain individuals or teams work on a specific feature that the development branch is created, the coding takes place, and the feature based branch is merged to the main source. This makes parallel feature creation possible.

For branching and merging strategy, there are plenty of great repository products, version control tools and source code management software available. However, this is critical as it needs to go inline with the entire development team and the same procedures must be used by all contributors.


As said, testing has been one of those functions that had “shift left” due to DevOps thinking. Testing is also one of those key areas that define the quality aspects of the software; despite no error, bug or issue is fixed by QA, all or at least majority of those can be discovered during this phase. As continuous integration has several goals for the testing phase, testing should be always automated to ensure seamless flow, rich and detailed results, and adequate verification of the application.

Continuous testing basically means testing each regression, build, and continuously practice this throughout the development lifecycle. Early testing, early validation and frequent testing ensure quality built-in to the application can be verified and issues to be tackled early. When Mobile DevOps is concerned with a production-like or real environment, the testing should always go on with real mobile devices. There are hundreds of good reasons why Mobile DevOps process should not include at this stage any use of emulators/simulators.

Screen Shot 2016-05-31 at 12.38.07 AM


The packaging step includes tools for package repositories and other storage mechanisms for the binaries created in the build step. Repositories, also known as artifact or asset repositories – contain all assets required and associated with binaries to facilitate deployments, such as scripts, configuration files and additional infrastructural files for deployment.

The continuous deployment adoption may not be ideal for every company (and developers), but the practice that enables releasing and deploying can also enable a seamless of a delivery pipeline and flow for Mobile DevOps. This flow facilitates the continuous deployment of applications to testing (or QA) and then all way to production, in an automated and efficient manner. The packaging step clearly supports the goal of continuous deployment to package and release new versions of applications (with new features) to end-users.


Most of the tooling and processes that make up the core of Mobile DevOps technology exist to facilitate continuous integration, continuous release, and continuous deployment. Part of this process is application release automation tools that help up the packaging and deploying an application from development to production (to be readily available for download/users), using automation.

These sort of tools aid Mobile DevOps flow to produce capabilities to implement continuous delivery for even large number of releases. In addition, release management and deployment planning with every release require collaboration across stakeholders. Release management tools allow organizations to plan and execute releases, provide a single collaboration portal for all stakeholders in a release, and provide traceability for a release and its components across all stages of the build and delivery pipeline.

Screen Shot 2016-05-31 at 1.21.08 AM


Configuration can be also seen as Infrastructure as Code (IaC) or Infrastructure as a Service (IaaS). IaC has been claimed to be a key attribute to enable full utilization of DevOps into organizations. With this, developers can be more involved in defining configuration and operations teams can get involved earlier in the development process.

Tools and methods that utilize IaC and IaaS can bring transparency to the configuration of the process and provide the visibility to users within the organization, aiming to bring teams together to maximize their efforts. Automation as part of the process can remove error-prone aspects of manual doings and processes, and make things more efficient and productive.

Configuration tools aim to allow the creation of better applications with flexibility, less downtime, and enhancing overall cost-effectiveness for the company. This approach is intended to reduce as many things creating complexity as possible by removing manual configurations. Automation and collaboration are the epicenters in Mobile DevOps and this is a reason why the configuration is also widely automated across development flows.


There is also an important aspect of making sure organizations get (only) valid data about the process, results in each step, and the outcome. Continuous monitoring provides that sort of data and metrics to organizations to evaluate all different functions of the process: development, operations, testing/QA, personnel and other individuals involved in the process. It’s important to remember that these metrics should not be measured only in production but during the process itself. When done properly as part of the process, enhancing and changing the daily-doings is easier and will have an impact on all steps.


Ville-Veikko Helppi

Mobile Testing Product Expert