Let’s talk a little about the application release process and why companies are increasingly using the Release Train practice.
Typically, releases in an application are made when a feature is finished being developed and tested. At this point, it’s ready to launch, isn’t it?
But, what about when we have several teams working simultaneously on different products of this app, for example, 20 squads or more? How to control and orchestrate this launch without losing quality?
When it gets to the point where managing a release becomes complex, adopting the mobile Release Train practice can help give the entire team more visibility, speed, and confidence in releases.
What is Release Train?
The concept of Release Train comes from SAFe (Scaled Agile Framework). He makes an analogy with a train that will leave for the trip at a specific time, and only passengers who arrive on time will board the trip.
That is if the feature was ready and tested, it can be part of this release. Otherwise, your team can wait for the next train departure.
How does Release Train work?
Check out the characteristics, operation, and benefits of this concept.
Setting the timebox
Applying the Release Train has several advantages. The first is that a schedule is defined for the release: every 1 or 2 weeks, or even every 1 month. The timebox is indifferent and will depend on the characteristics and needs of the project, although there is a tendency in the world of apps for more and more frequent releases.
Having a well-defined calendar brings visibility to the team (technical team, Product area, Marketing, etc.). Everyone involved knows exactly when the next release will be; the teams that didn’t manage to catch the train know that the next trip is on the way.
Once the train departure timebox (1, 2, 4 weeks) has been defined, it is necessary to establish what the cut-off date will be, often called Code Cut or Code Freeze. The cut-off date is the day/time limit to deliver the code ready, tested, and duly approved by the squad team.
For example: in the case of a weekly release, the cut-off date can be every Monday or Friday until the stipulated time. After that, nothing else enters the release.
Team performance
Before the cut-off date, all teams can work on their features and follow the entire development process. Generally, it consists of making a PR (Pull Request) for approval with Code Review by the technical leaders, confirming a good coverage of unit tests, and providing a build for the QA team of the squad to validate the functionalities of the new feature. Only when she is approved by the squad team can she be a candidate to catch the next train.
After this cutoff date, the squad is now free to work on the development of the next feature. Meanwhile, in parallel, feature integration and regression tests are started throughout the app to ensure the stability of the release.
This team that is already working on the next feature can also work on any bugs that may be found by the quality team in the regression tests.
Another important aspect of the Release Train is to define the necessary times for each of the test phases. For example, it could be 2 days for integration and 3 days for regression testing. All this, however, will depend on the size of the project and the number of QAs available.
It is important to emphasize that the QA team needs to be well-dimensioned, so that it does not become a bottleneck, delaying deliveries.
It may be that the QA team focused on regressive testing is unable to handle the number of features that are being made available. For this reason, some companies adopt a limit on the number of features that can be added to a release. Here, we make an analogy with a fixed number of train cars.
The release moment
When the time for the release arrives, we have small changes in the process that tend to vary according to the reality of each company. Some, for example, do all the tests only with the internal team. Others make a beta version of the apps available in stores before sending a definitive version into production. Many, still, can benefit from dogfooding, that is, they use their product.
Regardless of environments and release workflow, when submitting apps to the Google and Apple stores, it is good practice to do a gradual release (Staged Rollout) and use feature flags to control the availability of new features. Both techniques are used to increase release confidence and have a contingency plan in case any failures are found.
Gradual release
The gradual release is used to gradually release the version to the users, for example, starting with 10% of the base until reaching 100%. The advantage of this technique is that by gradually releasing an update to a small group, it is possible to identify and fix problems before they affect the majority of users.
Feature flags
Feature flags are a technique that allows turning on and off app features remotely. Among many applications worth a separate article, it can be used to roll back a possible issue in the release. Precisely for this reason, feature flags tend to give the team more confidence at the time of release.
Who organizes the release? Meet the RTE
To orchestrate the entire delivery, the Release Train practice recommends creating a role called a Release Train Engineer (RTE). This is the person responsible for organizing the entire release process, working closely with Product Owners/Managers, engineers, and all leadership. The goal is to ensure that all processes flow correctly to carry out a quality delivery.
In fact, for large apps, the RTE can rely on an entire team, which is often referred to as the Release Manager team. This same team or person may be responsible for updating store artifacts such as release notes, images, etc.
It is the responsibility of the RTE to approve all tested features to enter the release, trigger the responsible teams in case of failures in the integrated testing process, and even decide not to approve a feature due to a failure that has not yet been resolved in time for regressive testing.
Together with the entire quality team, RTE is responsible for ensuring delivery reliability and quality. Also, for triggering all teams to make the necessary alignments, giving due clarity to the next releases.
Final Thoughts on the Release Train
The Release Train concept is simple, but implementing it and keeping it alive is a challenge. Therefore, the RTE needs to act to remove possible impediments and ensure that the entire process is flowing correctly.
At the beginning of the article, a brief reference was made to the traditional release model, which consists of only publishing apps when we have a finished feature or an important update. This approach is not wrong; what has been shown here is a different view. The type of approach depends a lot on the context and moment of the project, and it may work for your app.
If we reflect on the main applications that we have installed on our cell phones, we will see that they are all going down a path of shorter releases, bringing constant value to their users. It’s a change of mindset: towards constant releases instead of a few releases full of news.
This technique allows teams to quickly experiment, use A/B testing, and collect data to validate what are pleasing users. It was first presented by the Dropbox team in the Fast Data-Driven Growth on Native Mobile keynote. The concept is to move from long releases, susceptible to failures, to short releases, and to migrate to a culture of experimentation and an agile process.
Some reminders and lessons learned:
- Define the period for each release. Starting with something feasible for your team, and decreasing the time as you gain maturity in the process. Each case is different; find a timebox that makes sense for your business.
- Share the calendar within the company. This helps all areas of Products and Marketing to be aligned with the launch.
- Define the time for each phase: development, cut-off date/time, time for integrated and regressive testing, and finally the time for the gradual release in stores.
- Define the criteria for getting on the train and follow them strictly. For example, don’t let untested features try to get on the train at short notice.
- Always keep the process running. The train needs to go even if there are only minor improvements.
- Automate everything you can. Having an integrated CI/CD pipeline is essential to generate releases quickly, whether for the squad’s quality team to test a feature, or to generate the final build of the app. The pipeline also helps to avoid errors caused by manual processes.
- Use e2e (end-to-end) automated tests to relieve the QA team. In addition to accelerating the regression testing process, it will increase delivery reliability and quality.
How can BRQ help?
BRQ Digital Solutions accelerates the Digital Transformation of your business, working from end to end, from the consultation process to application implementation.
We create the most diverse mobile solutions customized for your challenges, through continuous innovation with our engineering, design, and marketing teams. We also have a pool of exceptional partners, the largest technology providers in the market.
We unite technology, design, and business focused on the needs of the final consumer and connected to our client’s objectives, with a high level of quality and governance.
Does your business have a challenge? Talk to us!
Ricardo Lecheta, mobile specialist and Chief Technology Officer at BRQ.
