Introduction

I started a few weeks ago at QIMA. Wait, in fact, already a few months ago, time flies at QIMA. I had the chance to be a Release Captain recently and thought that it could be a good idea to share what this role is about because it was fun to do and it could be useful outside our team. Let’s first give a bit of context so you get a better understanding of what is the Release Captain role.

It simply started with a discussion with Gabriel, Adam and myself. Adam and I were still in the onboarding process (explained by Matthieu here) and Gabriel was our gentle “onboarder” :

  • Gabriel: “Hey guys, we need to talk about the next sprint, It’s going to be the support sprint for us”
  • Adam: “Go”
  • me: “Go”
  • Gabriel: “So the support sprint is … . <one eternity later 😉 >.  We will be overlooking two releases and we need Release Captain to take care of that!”
  • Adam: “Hey Jérémy, What do you think about being the Release Captain during the first release and I’ll take the second one”
  • me: “Let’s do that!!!”

At this time, I was not fully sure about what does this role mean but let’s be honest: Just the name of the role is cool.

« Hey daddy, what are you doing at QIMA? »

« The Release Captain, I am, my son »

The support  sprint

At QIMA, we release every week. The process is quite automated but anyway still requires a bit of effort and coordination. We are aiming at improving it with each iteration but we cannot forget about delivering business features. Did I already tell you that life is all about tradeoff?

We are organised in  teams and doing Scrum. In every sprint, one team is having a special sprint/role called the support sprint. This role is a floating role that every team have to deal with every {number of teams} sprints.

What is the goal of the support sprint for a team:

  • take care of the releases creation and deployment
  • fix and deploy blocking issues
  • check production state
  • handle all possible requests from everyone in the company (like « I need someone tomorrow for a customer meeting regarding technical questions », « Can someone check why this user is having issue X », «  The marketing needs an extract of this X data, Can someone help? », «  the CI is having an issue, can someone check? », …)
  • ask for help and escalade if it’s the fire in production

I see the support sprint as a way to isolate as much as possible other teams from the outside noise so they can focus on delivering business value.

Who is part of the support team?

  • all the Developers of a team
  • the Product Manager of the team
  • the ScrumMaster of the team
  • the member of the QA team usually working with the team
  • a member of the Techops team

Why is this support sprint so important?

A developer responsible for deploying and fixing production issues will not implement a feature the same way if they never have to deal with production issues. Why? Just because when you are responsible of the production you don’t want to deal with problems or fix emergency issues so you design and implement more simple and robust feature. That’s just human nature.

The Release Captain

The Release Captain is the one team member of the development team in charge of the support, who will focus on the release flow and to try to keep the defined timeline. The goal is to follow the release process from the release creation through deployment to testing environments and finally delivering a new version of the app to QIMAone users.

We have a dedicated support channel where all the stuff related to the support is happening. This channel becomes your best friend when you are the Release Captain. You have to be reactive regarding everything that happens here. Basically, as a Release Captain you need to take a step back to get a global view of what’s happening regarding the support. Every time a new issue is reported, you have to check with the Product Manager part of the team if it has an impact on the current release or not and take actions if needed.

As a Release Captain, you’re part of an awesome support team which means that you’re not alone. Basically, it’s the week where you spend more time chatting and having calls with others than during a standard sprint!

You usually start this role by creating the tag / release branch from the main git branch (and yes, it’s automated it also creates the changelog automatically). Then you need to check that all the builds are going well to the end. If you want more technical insights about the release train at QIMA, I would recommend this good blog post from Gabriel about that here

The release process is going through several steps of deployment into different environments :

  • It starts in the integration environment where all the stuff is continuously deployed from the main git branch. The product manager is doing a sanity check right before creating the release.
  • The release is then deployed to a demo environment where everybody can play or check things regarding the incoming release.
  • The release is also deployed to a QA environment. It’s a dedicated environment where all the regression tests are run. The full regression test suite takes a bit of time to run but it’s automated.
  • When you’ve got the green light from the QA team, you can go ahead and deploy to a preproduction environment. This environment is the closer to the production in terms of data. It contains a fresh anonymized version of the production database where the product manager can do a bunch of sanity checks.
  • Last but not least when all the lights are green, the release is deployed to production.

Each of the deployment to each of the environments are done by a member of the TechOps team in collaboration with the Release Captain and the Product Manager and anyone who wants to join. If you’re looking for more technical details about our deployment stack, there’s a nice blog post from Guillaume about that here

Everyday, first meeting of the day is the daily support meeting where the goal is to check where do we stand in terms of issues and release. As a Release Captain, you have to give an update regarding the release process :

  • What have been done yesterday?
  • What is the plan for today?
  • Are we on time regarding the current release schedule?

Finally the release is deployed to production. Then one last thing left to do is merging the release branch containing the hot fixes back into the main branch.

To be a Release Captain,  you need :

  • a good understanding of the existing release process
  • a bit of technical skills (especially regarding git)
  • a bit of communication skills
  • a bit of « keep calm and carry on »
  • a bit of «  keep calm and ask for help because you’re clearly not alone »

Why being a Release Captain is cool?

Being a Release Captain gave me the opportunity to discuss with a lot of people at QIMA that I did not yet have the opportunity to meet before.

One more thing

The Release Captain is not really an official role at QIMA. I did not find anything in the current QIMA documentation that explains what you’ve just read but the term is more and more used within QIMA. It’s more of a habit for the developers to have, when part of a support sprint, to ensure nobody is forgetting the release timeline. I’m not even sure all QIMA developers will recognise themselves while reading this but it’s what I had in mind when I did it 🙂

If you want to join this adventure, We’re hiring!

Written by Jérémy Sevellec, Software Engineer at QIMA