Release Management

Release management offers a great opportunity for having continued and successful software delivery in our clients' projects. This is the process of planning, scheduling and managing the software build in all the stages of the system development life cycle (SDLC)

As a project, usually, the products can be at the stage where the timeframe to create, test and stage a release could be days to weeks. It is the moment to work towards a more rapid release process which outlined aims to meet end-user expectations for timely feature additions and issues resolution

The release manager plays the main role in the Release Management process, coordinating the efforts among everyone who contributes to the release in order to achieve the goal. As a release manager, the primary focus is to have a continuous delivery of the product ensuring quality, coordinating with different stakeholders the scope, requirements, implementation, testing and getting the release in the calendar dates planned.

It is important not to confuse the release manager with the project manager. Both are related and work closely, but the Project manager focuses on the resource management, execution of the project, budget and deadlines, and may only deliver one or more components of the release.

Benefits of a release management

Having an effective release management process provides some benefits for the organization, such as::

• Increase the number of successful releases
• Decrease the number of defects
• Vision and goals are aligned with the scope of the releases, backlogs and epics.
• Continuous integration, testing and delivery
• Allows a continuous improvement in the process
• Increase productivity and communication from all the parties involved in the product
• Deliver software faster with good quality

These benefits are reflected in the value given to our customers, they will receive what they need with good quality and in the expected time, get to the point of Continuous integration where the changes are approved, and released to production.

Basic steps for a release management

Usually, a release management process is not the same for all organizations, due to that it is necessary to identify the state of the current release process, based on metrics of the release times, release types, releases delayed, and times of the release process. Once this is identified the following basic steps can be applied:

1. Identify the type of releases

According to the maturity of your product, you could have different types of releases, for example:

• Hotfix: These are rapid releases to resolve critical issues which have the Highest priority and it is affecting the users on production. When a release of this type is needed, this generally is a priority over all the tasks for the whole team involved.
• Minor releases: These releases are updates for the main version, aimed at a rapid cadence to include the fix for priority bugs and features that are important to the user. These releases usually do not cause an outage of the Production environment.
• Major release: This release is a major software upgrade, it could be a change in the full version of the product. This release may result in downtime of the Production environment.

Knowing the type of releases will make it easier to plan a release process according to each one.

2. Define a branch process and strategy

As part of the release process, the DevOps team provides a plan of action and strategy to achieve appropriate branch management, this strategy includes branch definition, semantic versioning, and a limited scope of branches by the environment in order to control the release package to install.

This step is also important to identify how a fix will be introduced in the release branch if there is any issue found during the regression testing of the release or user acceptance testing.

3. Definition of Done

Having criteria of Done for the requirements reduces the number of issues in the release and it will optimize the release process.

It is necessary to share this definition of done with all the team members, so everyone is aware of the quality expectations and they know what is needed to have a requirement done and what could block or affect the release as this definition of Done is reviewed for the cards that the team include during the sprint.

4. Identify Environments for Testing and stage

A crucial point for a successful release is quality. It is necessary to identify the environments where the QA team is going to ensure that the product meets the requirements. It is recommendable to have the following environments independent from the development one:

• QA environment: in this environment only the QA team should have access and the release version should be frozen before starting the regression testing of the release
• Staging environment: this environment should be similar to the Production environment to guarantee that the release version will work properly there, hence regression testing should be run here.

Having the previous definitions of the first 4 steps, the following steps are the ones that will impact each release:

5. Release planning

The planning phase is the most important step in a release process, the main goal of this is to identify the scope, schedule of all the activities needed and stakeholders to be involved in this. Doing release planning provides the team with a vision and understanding of the scope and schedule to ensure that they are on track and working for the same goal.

The basics that the Release plan should contain are:

• The main objective of the release
• Requirements that are in and out of the scope
• The timelines of the stages and delivery dates
• Team members are accountable for each activity of the release.
• Environments for development and QA certification

6. Share the Release plan with the team

After having this plan you will have enough information to create a roadmap of the release which will be visible for the whole team in an easy and clear way. Sharing the release plan with the whole team is key for a successful release, if the team has the visibility of this they will understand the deadlines and work for the same objective. Besides that, since there could be multiple teams working on the same release, sharing the plan could reduce the chance of causing conflicts of their release with one another.

7. Build the release

It is possible that the release of the product is composed of different teams who are responsible for different functionalities of this. With the release plan, each team will have the requirements that are going to be part of the scope so they can start designing, building and testing the product for the release

Build a release involving different stages and teams:

• Developer team who is going to develop the product
• QE team who is going to test and certify the quality of the product.
• Devops team who is going to ensure the environments, and that the release package that is going to be delivered is the same tested and certified by the QA team
• Product Owner: who is responsible to clarify any business doubt that the team could have regarding the requirements that are part of the scope of the release,

8. Testing and Staging certification

This is the stage that will provide the Release team one of approval to continue with the release, the QE team verifies that the product is working as expected without issues and that it meets the acceptance criteria of the release. The other approval comes from the Product Owner and any additional stakeholder that the organization decide to include as approvers.

Here the QE team plays an important role in replicating the possible scenarios that could happen on Production. Along with the manual Quality Analysts, the test automation team supports this process and optimizes the times of this stage, as well as the Security and performance team who could highlight important issues. Having a staging environment for certification reduces the risk of having issues on production.

9. Follow up and monitor the plan

It is very important that the release manager follows up the plan evaluating that the activities of this are getting done and their progress according to the planning. One of the ways to do this is through a checklist, listing the activities, role responsible, start date and end date in chronological order.

10. Release Approval release

Before the deployment to production or QA or staging environment (according to the environments defined), it is important to get the approval from the main leads involved in the release process: As a suggestion, the roles involved in the approval of the release are QA lead, Product Owner(s), Product Security lead (if there is one), Program Manager and any other role that the Release team consider include.

10. Inform, Deploy the release and Monitoring

After having the certification testing and approvals to deploy the release, it is time for the big day. Consider communicating in advance the schedule of the release to the primary stakeholders, Notice that for this step there should also be a plan to avoid any kind of mistake or to have a contingency for unexpected events.

Keep in mind to take into consideration the following aspects:

• The checklist for the release plan includes the task for DevOps, QA and users, this checklist should include all the steps that will be executed before, during and after the release. Part of the activities before the release should include a backup to the current version of production, data and any configuration file. This checklist could be different for each product.
• Communication of the scope of the release (defects fixed, new features), release time, duration and outage of time
• Rollback in case it is necessary due to any critical error not expected, This rollback is a process defined by the DevOps team.
• Smoke test to check that the new release does not introduce any issue and it is working as it was certified
• Roles available during the time of the release in case there is any error or doubt that should be reviewed with the dev or product owner
• User validation of access and workflow of the functionalities

After finishing the release do not forget to communicate the final result of the release to the team and stakeholders affected, continue monitoring this to be prepared for any eventuality.

11. Retrospective

Finally but not less important, we should always think of continuous business improvement, and that is why it is recommended to review after each release what went well and what we could do better for our next release with an action item for this.

Creating a release management process may need time in the beginning, but the reward will be in saving money, delays and having customers and users happier with a product more reliable and continuous delivery