Introducing Release Train

We’ve recently implemented a new release process, which brings much more structure and agility to our product. In this article I would like to explain the approach, why did we choose it, and what can you anticipate.

Why?

In the past, with the old platform, we used to release new versions of our app individually per airline.
Doing so for 30 airlines, made release planning nearly impossible.

Now with EFBOne, which is distributed centrally through the AppStore, we can move forward and modernize our release process.

The purpose:
1. To create structure and predictability around releases.
2. To offer better traceability for changes, aka release notes.
3. To bring agile, incremental improvements.

What?

Release Train is a methodology of making rapid releases based on a time schedule, rather than pre-defined deliverables.

In a release train, features are being merged into the pre-release until the cut-over moment, whatever wasn’t merged “misses the train” and will catch the following one.

Our Release Train will be tightly connected to our sprints, currently lasting two weeks each.
As you are using an MDM system for the distribution of apps to your crews, you don’t have to update the app with every release and are welcome to pick the ones that make a difference to you.

A week before the AppStore release, your EFB team will receive each new version for internal testing via TestFlight.

How?

We currently have three environments, which we are now fully utilizing as a part of the new process:

1. Development
2. Test
3. Production

Every “Train” will have 3 stops, starting at Dev and going to Production through Test.
Each stop is two weeks long, and the train departs every second Thursday at noon.

You will see this reflected in the Jira tickets status:

1. When a ticket is resolved it will move to “To do test”.
2. Once it’s tested and approved, it will move to “Waiting for pre-release”.
3. Every second Thursday, in the end of the sprint, new TestFlight version is created and all “Waiting for pre-release” tickets are moved to “Internal pre-release”.
4. On the Thursday of the following week, the TestFlight version is distributed to EBF admins, and “Internal pre-release” tickets are moved to “External pre-release”.
5. A week and a half after Monday, the TestFlight version is released to the AppStore and all “External pre-release” tickets go to “Released to production”. So on every second Monday, there will be a new release on AppStore

We hope this process will improve the predictability of when you can expect improvements to reach production while keeping our work process very agile. See you on the train!

If you are wondering how agility can make a difference for your airline- sign up for a personalized demo here.