Release trains are a type of time-based release strategy that consists of shipping new mobile app versions on a regular schedule. Contrary to feature-based releases, where you ship a new version of your app when a set of features are ready, release trains go out of the door at a fixed cadence, regardless of the features that are ready to ship at that time.
This approach resembles the way trains operate in the real world. Trains depart from the station at a fixed time and only passengers that are ready to board before the train leaves can get on it. Passengers who miss the train have to wait for the next one. In a mobile release train, features are passengers and the train is your app's version.
There are three stages in a release train:
- Release cut: This is the point in time at which you decide what features will be part of the release. To enforce this, you implement a code freeze, usually by creating a release branch with the latest changes from the development branch, and only allow critical bug fixes to be merged into the release branch.
- Testing: Immediately after the release cut, you start testing this version of the app to ensure that it meets the quality standards.
- Release: Given your app passes all testing requirements and has been approved by the Google Play Store or Apple App Store, you release the app to your users.
In this article, we'll explore the benefits of release trains and what key aspects you should consider when implementing this approach in your mobile app development team.
Why release trains?
Shipping new versions of your app on a regular basis allows your team to iron out the kinks in their release process and releases naturally become less of a big deal.
Release trains offer several benefits to mobile app development teams:
- Predictability: Release trains provide a predictable schedule for shipping new app versions. This predictability helps teams plan their work more effectively and reduces the uncertainty around the times when new versions will be released to users.
- Reduced risk: By shipping new versions on a regular schedule, you reduce the amount of changes that go out in each release. This makes each release less risky and easier to test, as you have fewer changes to validate. When issues arise, you can also quickly identify the changes that caused them from a smaller set of commits.
- Faster feedback loop: Release trains enable you to get feedback from users more frequently. This feedback loop helps you identify issues earlier in the development process and make adjustments to your app more quickly.
- Improved collaboration: Release trains encourage collaboration between team members, as everyone is working towards a common goal of shipping a new version of the app at a fixed time. This shared goal helps align the team and fosters a sense of ownership and responsibility for the app's success.
- Better planning: Release trains can help engineers and product teams align and plan ahead for when features might ship by aligning feature completion deadlines and milestones around the release train schedule.
- Your main branch is more stable: When release trains run on a tighter schedule, changes going into the main branch need to be in a shippable state. Release trains encourage the use of feature flags to hide features that are still in progress to ensure that the code in the main branch is always shippable, even if not all features are ready.
While the benefits of release trains are clear, implementing them requires careful planning and consideration of several key aspects. Failure to consider these aspects can lead to breakdown in communication, missed deadlines, poor quality releases and added stress and pressure on your team.
Define a fixed cadence that works for your team
The first step in implementing a release train is to define a fixed cadence for shipping new app versions. I wish I could tell you that there is such a thing as the perfect cadence that works for all teams, similar to the Golden Ratio in design, but the truth is that the cadence that works for your team will depend on several factors, including your team's capacity, the complexity of your app, and the time it takes to test and validate each release.
How do you find the right cadence for your team, you might ask? You should look at the data you have available to you and experiment. For example, you can start by looking at your team's current velocity and by calculating the amount of work your team does in a specific amount of time. You can get this data using the velocity charts most issue tracking solutions offer.
If you are currently shipping new versions every month, you could start by setting a cadence of two weeks and seeing how it goes. If you find that you are not able to keep up with the pace, you can always adjust the cadence to three weeks or a month.
Experimenting with different cadences will truly help you find the right balance between shipping new versions frequently and maintaining a high level of quality in your releases. It is also very important that you actively seek feedback from your team and stakeholders and act on it to improve your process.
Automation is key
One of the biggest challenges of moving from a feature-based release strategy to a release train is how many more versions of your app you will be shipping on a regular basis. For this reason, it is important that the release process is as streamlined as possible.
Make sure you automate manual tasks such as cutting the release branch, archiving and distributing the build and submitting to the stores. If you don't have a QA team or their time is limited, ample UI tests and a fully automated regression testing plan can help ensure that your app's critical features are working as expected before you ship a new version.
Feature launch communication
One of the biggest differences between feature-based releases and release trains is that with release trains, it can become very difficult to know which features are going out in each release. This can certainly be a problem for stakeholders such as product managers or marketing teams who need to know when features are going out to plan their marketing campaigns or communicate with users.
To mitigate this issue, you should establish a structured process for releasing new features. For example, you could always develop new features or significant changes behind feature flags and agree on a clear process and date to enable these flags in production. This approach ensures that stakeholders are informed ahead of time when features will be live, giving them the opportunity to prepare accordingly. Additionally, developing behind feature flags enables you to merge features into the main branch earlier in the release cycle, reducing the risk of conflicts and integration issues. It also gives you the opportunity to enable these features in debug environments and test them with real data before releasing them to users.
To further enhance this process, you can also compile and share a summary of all the changes being released with the relevant stakeholders, which helps communicate the scope of updates in a clear and organized manner. This not only improves transparency but also allows for better alignment between development teams and stakeholders.
Quality is non-negotiable
A while ago we wrote an article on whether there is such a thing as releasing an app too often. In that article, we went through numerous studies that investigated the impact of frequent app updates on user sentiment and app ratings and saw that the effect of frequent updates on your users' sentiment towards your app is directly correlated to the quality of such updates.
In other words, if you have built a great product that is already loved by many, frequent updates can help you maintain and even improve your app's rating and accelerate your growth. However, if your app is not well-received, frequent updates will usually result in more negative reviews.
For this reason, it is very important to allow enough time for testing and quality assurance in your release train and pick a cadence that allows your team to deliver high-quality releases consistently.
Conclusion
Should you use a release train in your mobile app development team? The answer is: it depends. Release trains are not a silver bullet that will solve all your problems, but they can help you ship new versions of your app more predictably, reduce risk, get feedback from users faster, and improve collaboration and planning within your team.
What I can tell you is that if you decide to implement a release train in your team and want to increase your chances of success, be prepared to experiment, actively seek feedback from your team and stakeholders, automate your release process, establish a process for releasing new features, and prioritize quality in your releases.
