“Release Train” in Software Development

Software Release Life Cycle is the sum of the stages of development and maturity for a piece of computer software: ranging from its initial development to its eventual release, and including updated versions of the released version to help improve software or fix software bugs still present in the software (source : Wikipedia).

Each life cycle can be varied depends on the product, the strategy & type of framework they used in software development. I would like to share the software life cycle that we used in my current company.

Before we go further, below are the conditions of our Teams :

• We are using Scrum Framework
• Sprints are 2-weeks time-boxed
• There are 9 Scrum teams working on different Products -> (April 2020 Update: There are 20 Scrum teams separated in 8 Tribes)

We called it “Release Train” for our software release life cycle. It’s not as advanced as Agile Release Train (ART) from SAFe but it’s actually our initiative to align and manage the software releases that happen in company.

We use Train Schedule as an analogy. Train schedules are fixed & well informed to train users. For example, everyday I go to work using Train. Every morning there are 2 departure time (on my time-range) from my station to my destination, which is 07:45 and 08:20. If I arrived in station before 07:45, I’ll take the first train, but if I’ve I arrived after 07:45, the train won’t wait for me & the other passengers, it will depart based on the schedule. It means that I have to wait for the second train.

Same method are being used in our Release Management. All the Technology team have discussed it and came out with agreed Release Dates. The agreed Release Dates are informed to all team & stakeholders. Release Dates doesn’t have to be at the end of Sprint, because Sprint cycle are not all the same within all Scrum Team.

Release Manager Role

As I mentioned above, we have around 20 Scrum teams and needs DevOps team to Release to Production. Managing Release for 20 teams at the same time are very challenging.

In order to manage the “Release Train”, we have Release Manager role for managing the releases for all the team. His/her responsibilities are:

• Coordinate & Align with all Scrum teams what are the Product Backlog Items that will be released
• Impact & risk analysis
• Facilitate Deployment meeting & create Deployment Plan with DevOps & Developer Team
• Discuss Rollback Plan with DevOps & Developer Team

By the way, currently this role are handled by one of Scrum Master.

Release Train Rules & Mechanism

We also has set the rules & mechanism (agreed by all Technology Team) for “Release Train” process. Below are the details :

• Release Dates are fixed and can’t be moved. If in one “Release Train” there are no story that can be released, so be it. (“Train” will depart with no passenger on it 😊). In our case, “Release Train” is every 2 weeks (April 2020 Updates: “Release Train” schedule is happen every week).
• Stories can be released partially. Example : In Sprint Planning, we planned 10 Stories. But at the end of Sprint, team only finished 8 stories. Those 8 stories can join the “Release Train”, while the 2 unfinished stories will join the next “Release Train”
• Deployment Plan Meeting / Coordination is a must. This is to ensure that all Scrum team are aligned each other and DevOps can be well-prepared for the Release. Ideally it should be done D-2 before “Release Train”
• Product Backlog Items that included in “Release Train”, will be informed by Release Manager to all related team
• If problem was found & impacting to other services, DevOps will perform Rollback only to the item(s) that triggered the problem.

Why we used Release Train at the first place?

• Reliability. By releasing regularly, we will build trust not only to Customer, but also to stakeholders. As I mentioned above, “Release Train” date is fixed. If the Release Dates can be changed, it will destroy the reliability that has been built
• By delivering services on shorter release cycles; the release management, test environment management and deployment processes are streamlined enabling changes to be deployed more rapidly. Customer realize the benefits of changes a quickly as possible
• Increased Collaboration. By bringing together multiple Scrum team & DevOps involved in the release management process, through information sharing and instant communication
• Mitigate Release Failure. Providing real-time visibility into enterprise-wide release status enables stakeholders & Scrum team to identify the root cause of potential release failures and mitigate them quickly
• By doing regular Release, DevOps team can be well-prepared managing the Releases. Review each Release result & improve it for the next Release (continuous improvement)

Closing. “Release Train” method are currently being used in our Scrum teams and it works really well. But we’re far from perfect, we’re regularly reviewing the process & always try to find a way to improve it.

It’s not a silver bullet. We don’t know whether it can be well-worked if you adapt this in your company. Because every team has it own characteristics. Allow the team to brainstorm, do experiments, do trial & error in order to find a perfect way for them.

Share your thought on below comment. ALL ABOARD!