Mobile app releases are usually complex, and the way different companies manage them can vary significantly. As a mobile software engineer, one of the most challenging aspects of your release process is dealing with the vast amount of tools and knowledge required to get an app out the door.
From version control systems to continuous integration pipelines, project management and design tools, and monitoring systems, many different platforms and services need to be used to manage a release process effectively. This distributed tooling can lead to a series of problems that I have experienced firsthand during my career and want to share in this article.
Common tools used in a mobile release process
As part of the release process, mobile software engineers need to perform a series of tasks using a variety of different tools that you need to be familiar with when managing a release:
Version control systems: A big part of the release process is managing the lifetime of the release branch, merging code and resolving conflicts where needed, for which the use of a version control system is essential. Releases usually start with the creation of a release branch where the app version is bumped and they tend to end when the release branch is merged back onto the base branch after the release is published to all users. These common Git operations and their associated side-effects (such as bumping the version when creating a release branch) should be fully automated using CI/CD workflows.
CI/CD pipelines: Continuous Integration and Continuous Deployment pipelines are used to automate the process of building, testing, and uploading an app to the relevant stores or distribution channels. Contrary to what most people think, while CI/CD pipelines are crucial to automating manual tasks and streamlining the process of releasing an app, they are not the only part of mobile release management. Services like Jenkins, CircleCI, Bitrise, and GitHub Actions are commonly used to set up mobile CI/CD pipelines.
Knowledge repositories: To ensure that the release process is documented and that the team has access to the information they need to perform a release, most teams use manually maintained guidelines and documents that are hosted in one or more knowledge repositories such as Confluence or GitHub wikis.
Build distribution: Once the app is built, it needs to be distributed to the relevant stakeholders and beta testers for testing and review using services such as TestFlight, Google Play Console, Firebase App Distribution, or AppCenter. Each of these services has its own way of uploading and distributing builds and you usually need to manually integrate it into your CI/CD pipeline.
Feature toggles and configuration: To be able to release features to a subset of users, experiment with different configurations, or enable/disable features remotely, many teams use feature flagging or remote configuration services such as LaunchDarkly or Firebase Remote Config. Most mobile teams know that releasing mobile apps isn’t like releasing other kinds of software — updates are usually slow and can take up to a few days to be reviewed and approved by the app stores. This makes feature flagging and remote configuration even more critical as a tool to mitigate the impact of bugs in production, making it crucial that the release managers are familiar with these services to be able to quickly disable features if an issue were to occur during the release rollout.
App store console management: Being familiar with the store's console for the platform you are shipping to is very important when releasing mobile apps, as you usually need to access it to update metadata before a release, monitor reviews and ratings, and stop the rollout of your release if needed. On the Apple App Store, you can use App Store Connect and on the Google Play Store, you can use Google Play Console to perform such tasks.
Localization and internationalization: If your app is available in multiple languages, you need to be familiar with the localization and internationalization tools used by your team to manage translations and ensure that the app is correctly localized for the target audience. To save time and reduce the risk of errors, it’s common to download the latest translations from a translation management tool like Lokalise as part of your app's release CI/CD pipeline.
Project management: Teams usually keep track of the state of work going into a release using a project management tool such as Jira or Linear. Both feature work and bugs are tracked using your team’s project management tool, and because managing releases is so much work, it’s also common for release managers to create a “release manager” ticket to be able to track their work during the release process and ensure that all tasks are completed before the release is shipped.
Communication: Contrary to what most people think, an app's release is not solely an engineering concern. There are numerous stakeholders involved in the process such as product managers, designers, marketing teams and customer support that either need to be informed about the release or need to provide assets and information to be included in the release. In most companies, the release manager tends to be the main point of contact for all stakeholders and is responsible for ensuring that everyone is informed about the release and that all assets are ready before the release is shipped using communication tools such as Slack or Microsoft Teams. Email sometimes also comes into play for sending summarized updates or for sharing updates more broadly with folks across the org.
Stability and performance monitoring tools: Once your app is released, it is very important to keep an eye on the app's performance to be able to quickly identify and react to any issues that might arise. To do this, most teams use stability and performance monitoring tools such as Sentry or Crashlytics to track new crashes.errors, and performance issues for specific releases. Release managers are typically responsible for using these tools to keep an eye on the stability of a release as it rolls out.
Observability and Analytics: Not all issues in your app are crashes or errors. Sometimes, a release can cause a drop in user engagement or can negatively affect your key metrics. To prevent these issues from going unnoticed, most teams use observability and analytics tools such as Datadog or Amplitude to monitor events and metrics sent by the app in production. Once again, it’s important for release managers to be familiar with these tools so they can monitor the health of releases as they roll out.
As you can see, there are many different tasks that release managers have to own and manage during a release process. Each of these tasks usually requires the use of one or more different tools, increasing the complexity of the release process and the cognitive load on the release manager.
The problems caused by distributed tooling
Cognitive overload
As you can imagine, managing all these different tools to successfully deliver and monitor a release can be complex and overwhelming. Release managers not only need to be familiar with these tools and quickly switch between them, but they also need to be able to understand how to parse the information provided by each of them to make informed decisions.
Some of these tools have integrations that only notify when an issue occurs, which makes things easier. However, most of these integrations just post a link to the issue in the team's communication channel, which still requires release managers to switch context and understand the issue before they can take action.
Context switching
In most teams, the release manager is a product software engineer who takes some of their time off from their regular work to manage a release. While some means of context switching are unavoidable and can be managed, if the release process is complex and requires performing a lot of tasks manually in different places, release managers will spend a lot of time away from what they are best at: writing code.
Release manager rotations can usually help with this problem as they allow the team to share responsibility for the release process and ensure that not one person from the same team is always responsible for managing a release. However, effort needs to be put into ensuring that the context switching and effort for the release manager is as low as possible.
Documentation
A crucial part of a successful and smooth release process is having enough good documentation that is up-to-date and easy to access so that the release manager can follow. This documentation must contain a list of actionable items and steps that the manager needs to take to successfully deliver a release.
However, a lot of teams maintain their documentation manually and in different places, which usually leads to it being out of date and hard to find. This can lead to the release managers missing important steps or having questions that might inevitably bring other engineers into the process and slow down the release process.
Communication breakdowns
As mentioned earlier, an app's release is not solely an engineering concern. There are numerous stakeholders involved in the process such as product managers, designers, marketing teams, quality assurance analysts, and customer support that either need to be kept informed about the release or need to actively contribute assets and information to the release.
If release managers are not able to effectively communicate with stakeholders promptly and clearly, they might miss important information or assets that are needed for the release. This can lead to delays in the release process and can cause frustration among stakeholders.
This can certainly happen when the release manager is juggling multiple tasks and tools, is overwhelmed and is doing the communication manually.
Managing seats and licenses
Most of the tools used by companies during a release process require a license and have a limited number of seats. This increases the cost of the release process, makes onboarding new team members harder and can lead to delays in the release process if the release manager is not able to access the tool they need to perform a task.
Teams usually solve this problem by either giving everyone who could lead release access to all the tools they need during onboarding or by having a shared account that the release manager can use during the release process. However, most of the time release managers don’t need a full license and only need access to a subset of the tool's features, which can lead to a waste of resources and can pose a potential security risk.
Complex integrations
A lot of the problems above can be mitigated by having good integrations and automations between the tools used during the release process. However, these are often not available out of the box and teams have to build them from scratch and maintain them over time.
Automating manual tasks and building integrations across tools can have significant impact, because it reduces the cognitive load on the release manager, minimizes context switching, and ensures that release managers have access to the information they need to make informed decisions. However, building and maintaining these custom automations and integrations can be time-consuming and the skillset required to build them is usually different from the one that a mobile software engineer has, increasing complexity further.
How can we mitigate these problems?
The most effective way to mitigate the problems caused by distributed tooling is not to reduce the number of tools used during the release process — as each of them excels at performing a specific task and very likely provides value to the team — but instead to ensure that the release manager has a single place where they can oversee the release process and that automations are in place to react to issues either automatically or by alerting the release manager only when strictly necessary.
This single place, which could be an internal or external platform such as Runway, should provide the release manager with a high-level overview of the release process, the ability to perform tasks and access information from the different tools used during the release process and automate manual tasks as much as possible. It is also important that this tool enhances collaboration and communication between all parties involved, ensuring that they are automatically informed and involved in the process on a need-to-know basis.
By providing release managers with a single place to manage the release process, we can reduce the cognitive load on the release manager, minimize context switching, ensure that the documentation is up-to-date and easy to access (the platform itself should serve as a documentation of the process), improve communication between all stakeholders, reduce the cost of the release process, and ensure that the release manager has access to the information they need to make informed decisions.
Want to hear even more about the problems with your mobile release knowledge and tooling be way too distributed? Watch Pol's video on this topic.
