Release manager – why you need one
Hello! My name is Ksenia, I have been involved in releases for more than 7 years and now work as a release manager at RuStore. Today I want to tell you more about this role, in what cases you need it (spoiler, not always) and when it can be transferred to another employee.
One day I was faced with a classic question from parents: “What do you do at work?” And I thought, how can I easily explain this… The developer develops, the tester tests, and me?
And I’m a conductor in an orchestra – although it sounds like a cliché, it’s true. There are many different teams involved in the release process. It would seem developers and testers, and who else? In addition to the development and testing teams, every day I interact with a huge number of different IT departments, for example, support, information security, DevOps, technical writers. I also communicate with marketing, product managers, etc. All these people need to be coordinated, correctly convey information, organized so that in the end the melody (that is, the release) turns out to be harmonious and everyone plays their part exactly when and as needed.
Here is a short diagram of my daily interactions:
When is this role needed and when is it useless?
Most often, a release manager is needed in a complex and rapidly developing product, such as RuStore, where it is necessary to maintain high quality development.
In my work I solve the following questions:
– First of all, this is coordination: Ensuring effective collaboration between different teams and departments.
– Can’t do without a release manager and planning: Determining the composition of releases, planning development stages and milestones.
– Of course we need it process control: Monitor all necessary inspections and approvals and ensure compliance with schedule.
– Necessary and automation: Creating and thinking through tools to speed up and simplify the release process.
– Line-up communications: Informing all interested parties about the stages of preparation and installation of the release.
– And last but not least – audit and optimization: Conducting process audits and improving weak points.
Using the example of the task life cycle, you can see that my work covers almost half of the cycle.
What has changed in a year
How we started
When I came to RuStore, there were releases once a week. The project managers and I gathered for a meeting to form a release scope, clarify the status of the task, statuses, list of services, etc., and DevOps engineers were engaged in preparing the release for installation.
Almost everything was done by hand and took a lot of time and effort. The release cycle diagram a year ago looked something like this:
The general process flow was the following:
Optimization
The project evolved and the team structure changed. So, instead of project managers, we had many feature teams, and the release process needed to be reconsidered.
We handed over the preparation of services for release to the developers – they compiled instructions, merge requests, etc. Thus, DevOps engineers were able to devote more time to setting up automation.
When moving to feature teams, we had to collect detailed information about the installation of services for each team. We asked team leads to fill out checklists describing changes, connections between services, toggles, etc.
At the general meeting, we discussed the nuances of installing all the improvements; on the basis of this, I drew up a plan for roll-up and rollback of the release, collected and clarified other details.
This approach took a lot of time and effort from the team leads, me and my colleague. Realizing that without automation of releases it will not be possible to refuse these meetings, we simultaneously set up:
automatic linking of all ready-made tasks to the release;
automatic collection of a list of installed services.
At this moment, we were faced with another task – to develop a plan to increase the number of releases. To do this, it was necessary to shorten some steps, such as testing and preparation for installation.
How we shortened the release testing stage
Reconsidering approaches to testing and automated tests is all clear, but what does the release manager have to do with it?
My colleague and I had to solve the problem of installation on test benches. Those responsible for the services manually carried out the release candidate section and installation, which took about 5-6 hours, and we understood that it would be more useful to allocate this time for testing. The problem was solved by setting up automatic cutting of release branches and automatically installing them on test benches. This allowed us to reduce the time required to prepare a release candidate. from 6 o'clock to 1 o'clock.
How it was before:
What happened after:
So, automation helped speed up releases and freed up additional time for testing. It became easier for teams to plan regressions and tests, and we stopped holding release meetings.
When is a release manager not needed?
In such fast-growing projects as RuStore, it is impossible to do without a release manager. But there are situations when it is not necessary to allocate a separate role for the release manager on a project:
The project is at the startup stage – there are not many employees involved, and everyone communicates effectively with each other.
Someone on the team is not heavily loaded and can take on an additional role.
The project has a very high level and culture of development and automation, but all processes change quite rarely. This also happens.
A release can be managed by any member of the team who is involved in any way in preparing or installing the release.
Most often this will be someone from testing, DevOps or product managers.
But as soon as the project begins to grow, it is worth thinking about assigning a separate role, because it will allow it to develop much faster and with better quality.
What's the end result?
The release manager is not always a visible, but very necessary role, which ensures that high-quality code is delivered to users as quickly as possible.
Over the course of this year, I have further improved my automation skills; many processes had to be built from scratch. I figured out Omicrone (our toggle management system), helped the team move from one management structure to another, adapting our releases to this without losing their quality and quantity. Much remains to be done, but that's a completely different story.
We will continue to talk about the release management process – in the next article we will tell you how to auto-cut releases.
