5 ways the best mobile teams use release trains for increased speed and efficiency

Key takeaways and best practices shared by product managers and engineers using the mobile release train approach to help you improve and optimize your release cycles and make more informed decisions about your app releases.

Releasing with speed and confidence is every mobile team’s dream. To help you on that journey, mobile release trains can introduce a quicker release model and faster mobile cycles — making distributed development teams, that work on different parts of an application, become more aligned — regardless of their size.

If you are new to the mobile release train methodology and you want to learn more about how to drive speed and release quality through implementing this approach for your teams, have a look at our extended paper here. 📄 🚀

Lyft, Soundcloud, and Skyscanner are just some of the companies that leverage the mobile release train as a scaled agile framework for better planning, increased release efficiency, less risk, and a better visual feedback of the status of builds.

We collected key takeaways and best practices shared by product managers and engineers using this fixed schedule approach — to help you improve and optimize your release cycles and make more informed decisions about your app releases.



Use release trains for better collaboration and less risk

Working in two-week intervals gives us time to test and prepare each update, and make changes to our apps very quickly. Because each update contains fewer changes, it also reduces the risk that we’ve added something that doesn’t work, and makes it easier to address any issues that come up.

— Senior Product Manager, Monzo Bank

Knowing when a release is scheduled for in advance has allowed us to communicate more effectively with our editorial teams, allowing them to promote new features and have a better understanding of timelines, while we have also been able to push out well-tested fixes more regularly.

— iOS Developer, Reach PLC

Following a release train gives everyone a sense of predictability over when changes will be rolled out to the public. As a result, our design and data analysis teams can estimate when their help will be needed for defining and delivering specifications for feature development; product managers know when their experiments and product launches will go live; and the engineering teams are able to plan their work to aim for certain code freeze dates.

— Software Engineer, Soundcloud



Identify a release manager for smooth, consistent rollouts

This person will have the responsibility and authority to push out releases and build trust in the method across the entire organization. Usually an engineering or product manager can fill this role well. The release manager needs to get the team and the organization onboard, as well as demonstrate the benefits of tweaking the workflow.

— Product Manager, Lyft

Once a code freeze happens, release captains are responsible for performing a set of manual regression tests that cover the main use cases of the application and some of the scenarios we could not automate (yet). Once all is verified and the captains feel confident with their release, they are free to start the staged rollout process by deploying the build to the beta channel and subsequently rolling out to percentages of the production user base.

— Software Engineer, Soundcloud



Introduce feature flags for increased release confidence and staged rollouts

Because features take different amounts of time to finish, we sometimes make changes to the app but leave them hidden behind “feature flags.” We can release this code to customers, without actually giving them access to the feature. Once the new feature is ready to go, we can remove the feature flag so it’s available to everyone, without having to release a new app update.

— Senior Product Manager, Monzo Bank

By using feature flags, we are able to specify which features the users should see when they run the application. The feature flags can be modified remotely, so we are able to turn on and off features without releasing a new binary. Once we finish the development, we release to 1%, 5%, 20%, 50% and finally to 100% of our users using the feature flags. Meanwhile we continuously monitored the performance of the feature.

— Senior Software Engineer, Skyscanner



Enhance flexibility for consistent multi-platform releases

Having a fixed release train schedule allows for additional flexibility when unexpected issues arise. Being strict actually gives you more flexibility. In that if you have that high profile request coming, you can put that on the next train. Instead of dropping everything to take care of a high priority change, current development can simply be postponed to the next release, rather than derailing the entire process.

— Product Manager, Lyft

When we’re working on a feature on both iOS and Android, we have a couple of options for how to release it. We can release it on one platform first, then bring it to the other one the following week. Or, we can wait until the feature is finished on both platforms, and make it available to all users at the same time. The two weeks give us time to identify and fix bugs, and address some early feedback we receive from our first iOS users.

— Senior Product Manager, Monzo Bank



Adopt a continuous integration tool for speed and automation

Having a short release cycle is vital if you’re trying to make small, iterative changes to improve your app quickly. It gives you the ability to react to the market and learn quickly from your users. Make sure you have the right set of tools that allow you to operate at this speed.

— Product Manager, Lyft

Being confident about releasing software — with as many features, code contributions, and devices that we have to release for — is no easy task. Therefore, we have introduced many tools and practices in our release process to aid us. By using continuous integration tools, we ensure that our master branch is always deployable.

— Mobile software engineer, Soundcloud

By using CI tools, we ensure that our master branch is always deployable. This is accomplished by scheduling time-based jobs to be run — either nightly, weekly, or bi-weekly — or via triggered jobs (for example, when a pull request is merged into our master or release branches). With these CI jobs, we can guarantee our obfuscated and shrinked release builds are all set, updated to the latest localized translations; and that repetitive tasks are automated.

— Software Engineer, Soundcloud



If you are new to the mobile release train methodology and you want to learn more about how to drive speed and release quality for your teams, have a look at our extended paper here.

Get Started for free

Start building now, choose a plan later.

Sign Up

Get started for free

Start building now, choose a plan later.