From zero to Release Management

According to ITIL, Release (and Deployment) Management is the process of managing, planning, scheduling and controlling the rollout of IT Services, updates & releases to the production environment. This means that every company or community has a process to release and deploy in place, whatever it is. No matter if it is a formal or informal process, if it involves many or few teams, stages or environments, if the most fancy devops tools are used or not. Whatever you do to put your new code in your production platform, there is a release management process in place.

That being said, this process comes in all shapes and sizes, and the requirements may change from one company to another. There is no magic formula and every company or community should understand in what stage is and what their needs are. However, there is some common ground to be taken into account when trying to develop or even create from scratch a full release management process.

Analyze what is currently being done

At the early beginning, an assessment should be carried out to understand how the process currently works. This assessment should include the elements below:

• Development workflow: Understand all the steps and actions about how and when the code moves from the developer teams to the production environments.
• Version control system: Understand how the code and versioning (at code and release level) are managed and what tools are being used.
• Environments: Understand how many environments there are and what their role in the landscape is.
• Testing process: Understand how and what types of testing is performed (unit tests, regression tests, user acceptance tests, performance, integration, security, etc). Someone from the QA team should be involved here.
• Teams involved: As we did with the environments, we should understand the teams involved and their role in the process. In the end, we are working with people and everyone should be involved in the reached agreements.
• Deployment frequency: We need to understand what are the requirements of deploying changes into the production environments in terms of frequency.

Initiate the changes

Once the initial assessment has been done, we should decide which parts of the process we should stay with and which parts we should not. Remember: There is no such thing as good or bad. Simply try to keep within the process what works for you, and try to remove what doesn’t.

Once we have a clear vision on which items work for us and should stay, define the release management process only with them, and make it work from this point onwards. Except for exceptional situations, the changes will be introduced step by step, without being too intrusive in the process, making one change each time. Bear in mind this is not the final process.

Improve the process

Once we have the process as we want it, we will be introducing changes as they become necessary, whether due to technical requirements or business needs. We might also want to add new tools into our technology stack, or add new processes (such as Continuous Integration or Continuous Delivery/Deployment) to adapt to new scenarios.

The Release Management process is alive and changing, it should never be static, and it should be able to adapt to the needs of different teams at any time. The process must be systematically re-evaluated to seek continuous improvement.

Final considerations

1. Use a control version system! Development life cycles cannot be understood nowadays without them. You can also use some of the platforms built around them such as Github, Gitlab or Bitbucket.
2. Document, document, document! Document all the steps of the former and new process, create release calendars, write all the meeting minutes and their reached agreements, define task workflows, create (and follow) policies for the most critical areas, etc. Write it all down!
3. Measure as much as you can. Define some KPIs that make sense for you (releases, services, tests, etc) and get some numbers from them. Remember: If you can’t measure it, you can’t improve it.
4. The code versioning system (such as Semantic Versioning) might not be useful for releases with several services/areas. Define a versioning system according to your needs (by area and date might be a good practice).

Remember there are several strategies for managing releases. No strategy is better than another, we just should find out what works well for us, an what doesn’t :)

Happy release!