What is release management? A clear explanation

Release management is the set of practices that development teams use to plan, schedule, coordinate, and deploy software releases across environments.

Stable and resilient software runs the modern world. But let’s face it, bad releases happen all the time, and even tech giants aren’t immune to it.

The infamous Crowdstrike Falcon Agent update caused the BSOD (Blue Screen of Death), affecting 8.5 million devices on July 19, 2024. Airlines halted. Manufacturing and transportation were disrupted. An estimated loss of $5.4 billion was reported from the Fortune 500 alone.

This is why delivering software updates reliably, efficiently, and without disruption is a critical discipline. Release management forms the backbone of this discipline, enabling organizations to balance speed to market and stability.

In this post, we’ll discuss what release management is, its importance, and the associated process.

Release management is the set of practices used by development teams to plan, schedule, coordinate, and deploy software releases across environments, from development all the way to production

Key takeaways

• Release management ensures coordinated, low-risk software releases across environments.
• The process includes planning, building, testing, and deployment stages.
• DevOps enables faster, automated, and collaborative release cycles.
• DORA metrics measure release performance and reliability.
• Strong practices and documentation reduce failures and improve outcomes.

What is release management?

TL;DR: Release management is a set of practices used by development teams to plan, schedule, coordinate, and deploy software releases across environments. Its primary goal is to deliver updates with minimal risk and disruption.

Release management is the set of practices used by development teams to plan, schedule, coordinate, and deploy software releases across environments, from development all the way to production.

The primary objective of release management is to deliver new features, bug fixes, and updates promptly, without disruption, and with minimal risk.

Why is release management important?

Today, multiple DevOps teams work simultaneously to develop and ship updates to the same product. Every commit needs to be synced, and every subsequent release needs to be communicated, coordinated, and executed seamlessly to prevent disruption.

Imagine your company is working on a new fitness app.

One of the dev teams creates a new weight-tracking feature. But before the code can be pushed to production, they need to build, test, and deploy the code in multiple environments.

Other dev teams and site reliability teams need to be kept in the loop to avoid conflicting code deployments and instability in software.

This is where release management helps:

1. Reduces downtimes and risk: Structured and well-coordinated releases minimize deployment failures and ensure the high software uptime that consumers expect.
2. Improves compliance: Proper release management enables logging and audit tracking that help fulfill regulatory requirements such as GDPR and SOC2.
3. Faster time to market: Reliable, standardized, and continuous deliveries help dev teams to ship features faster.

The importance is summed up by Jez Humble and David Farley in their book Continuous Delivery: “Releasing software is too often an art; it should be an engineering discipline.”

A brief history

Earlier, release management relied on manual deployments that had a waterfall-based approach. However, the process was slow, cumbersome, and error-prone.

The demand for accelerated software delivery triggered the industry to adopt a more Agile and DevOps-centric approach. A report by Compuware found that 97% of IT teams are under pressure to deliver accelerated software and innovation.

Today, software releases are automated and rely on a data-driven, continuous delivery approach. In the present day, CI/CD (continuous integration/continuous deployment) releases happen faster than ever, sometimes even several times per day.

Release management processes have been refined over the years, and the exact processes and tools can vary between organizations and teams

Release management process

TL;DR: The process typically includes planning, building, testing, and deployment stages. While it may vary across organizations, these stages ensure structured and reliable releases.

At this point, you might be wondering: What are the key stages involved in the release management process?

Release management processes have been refined over the years, and the exact processes and tools can vary between organizations and teams. However, the key stages are detailed below.

Stage I: Planning

During the planning phase, dev teams will work together with other stakeholders and decide:

1. What features or fixes will be included in the release? Such as: “Agoda adds a real-time currency conversion based on spot FX during checkout.”
2. Dependencies on other modules or systems, such as: “Is the source data API ready and formatted according to the requirement?”
3. Potential hazards, along with the specific strategies to mitigate these risks, such as: “Netflix plans a video codec update and assesses if it will disrupt streaming across devices.”
4. Schedule in terms of the release dates and timelines.
5. Any business continuity plans (workarounds) or rollback strategies, such as: “If our order processing software goes down, we will use a manual register to track and process orders.”
6. Definition of done and success metrics, such as: “Achieve release with zero downtime.”
7. Roles and responsibilities (developers, testers, operations).

The dev teams will typically work with the business to coordinate any downtime and potential impact. A well-thought-out release plan is iterative and reduces negative impact on the business.

Stage II: Building

Here, the goal is to package all of the code, associated configurations, and dependencies into a deployable unit. Development teams will:

1. Write and commit the code

Developers will convert functional requirements into technical requirements and code.

2. Document records

Document records for all modifications done and maintain version control. Ensuring an audit log is important to trace back any errors and help successive teams understand the codebase on what changed and why.

Stage III: Testing

Testing is a crucial part of release management. This is where we determine if the resulting codebase is working as expected and deployment-ready. A variety of tests are undertaken as part of this stage:

1. Functional testing: Ensure that the intended functions are working properly.
2. Regression testing: Check if the new changes have caused any negative impact on the previously existing functionality.
3. Performance testing: See if the software can bear the expected loads.
4. Security testing: Identify any vulnerabilities and patch them before moving to production.
5. User acceptance testing: Verify that the intended changes meet business requirements. (Typically done by a key user from the business.)
6. E2E testing: Business and dev teams work together to ensure that all modules are working end-to-end. Products like qTest can help accelerate the process and release faster.

Many teams often underestimate the time taken for testing. Depending on the complexity and scope of changes, teams should allocate an appropriate amount of time in order to do a quality job.

Stage IV: Deployment

This is the last stage, where the business and product teams sign off and move the release to production. The product is essentially released to the end user. Documentation and user guides are provided. Any training needed is delivered.

The activities are coordinated with the operations team, and after a hypercare period, any further operational issues are onus of the operations teams. Main tasks include:

1. Verifying that the production environment is configured correctly and ready to host the release.
2. Executing deployment scripts and pipelines.
3. Coordinating with relevant teams and end users.
4. Monitoring for any post-deployment issues.

Whether a change was successful or not can only be determined once it is released.

Michael T. Nygard mentions this in his book, Release It!: Design and Deploy Production-Ready Software: “Release is the beginning of the software’s true life; everything before that release is gestation. Either systems grow over time, adapting to their changing environment, or they decay until their costs outweigh their benefits and then die.”

What is release management in DevOps?

TL;DR: DevOps transforms release management by emphasizing automation, collaboration, and continuous delivery. It shifts quality checks earlier in the process to reduce risk while increasing speed.

DevOps fundamentally shifts how software teams operate and release software. Before the advent of DevOps, dev and ops teams worked in silos.

Developers would toss code over to the operations teams, who would then scramble to deploy it. Due to time pressures, the interest of the devs would be to deliver functionality. Documentation and “sustainability” of the code often took a back seat.

The result was a sloppy, painful process that caused apps to break down in production and caused a lot of conflict (and, unsurprisingly, resentment) between the two teams. Blame games would erupt, bringing an unpleasant tinge to the culture.

DevOps attempts to solve this mess. The unified goal becomes delivering increased value to end consumers at a faster pace.

This is done by reducing bureaucratic quality gates and lengthy approvals. At the same time, as many processes as possible are automated, and observability tools are installed to monitor the pipelines 24/7.

Automation and speed redefine release cycles

Advanced toolchains and streamlined processes have made it possible for release cycles to go from weeks down to a matter of hours. Manual environment provisioning that took days and weeks to coordinate can now be spun up in a matter of seconds. That, too, is now on demand.

Rollbacks once needed all-hands calls and hours of collaboration. Now these can be triggered automatically as soon as observability tools pick up anomalies.

All this sounds exciting, but as developers, we need to be cautious too. Speed without the right discipline can be dangerous. We saw this with the CrowdStrike incident that we talked about earlier.

This is precisely why release management in DevOps isn’t about removing the guardrails, but more about moving them earlier in the process (shifting left). The goal becomes to catch issues in development before they even reach production.

A release manager is the person tasked with planning, coordinating, and optimizing the release life cycle.

What is a release manager?

TL;DR: A release manager plans, coordinates, and optimizes the release lifecycle. They work across teams to ensure smooth execution and alignment with business goals.

As mentioned earlier, release management methodology has come a long way and evolved into an intricate practice. This has given birth to a new role: release manager. But what’s the role of a release manager?

A release manager is the person tasked with planning, coordinating, and optimizing the release life cycle.

Again, the responsibilities might vary from team to team and between organizations, but generally, a release manager is responsible for:

1. Scheduling and managing a product’s release calendar
2. Collaborating with business, operations, product, and development teams
3. Leading GO/NO-GO decisions at various milestones
4. Ensuring that each release complies with business requirements, policies, and is compliant
5. Gathering feedback based on reviews from the business after the release is done

Since the release manager needs to work across domains and teams, the assigned individual should have strong cross-functional knowledge, leadership, communication skills, and risk management skills.

Some might confuse the roles of a project manager and a release manager. However, both have distinct roles. A project manager leads the entire life cycle of a project and is involved in the end-to-end planning, budgeting, and execution.

They are responsible for the project from planning to closure. Release managers, on the other hand, are limited to the specific release process only. Both roles work closely together for the delivery of a successful product/service.

Key roles in release management

TL;DR: Release management involves multiple roles, including product managers, developers, QA, DevOps, SREs, and security engineers. Each contributes to different aspects of building, testing, and maintaining releases.

Release management isn’t a one-man show. It’s a team sport where each role plays a critical part in the process. We already covered the role of the manager, so now we’ll discuss other key players involved.

1. Product manager (PM)

A PM owns the product backlog and fleshes out the business requirements with the stakeholders. They define what value the release needs to deliver.

The product manager gets involved in prioritizing the features to be developed for each release, defining the user acceptance criteria, and acting as a major stakeholder in the post-release reviews that confirm that the release actually did achieve its intended targets.

2. Data engineers/software engineers

They’re responsible for writing the code and building the data pipelines. Documentation is a large part of their job. Following good hygiene when it comes to version control pays high dividends.

3. QA engineers and testers

These folks come in to design and execute the test strategy for each release. They perform a number of tests, including functional, regression, performance, unit, and security. This testing ensures the release is airtight and works robustly.

4. DevOps engineers and platform engineers

They manage and provision the infrastructure required for the applications and subsequent releases.

Maintaining the CI/CD pipeline and deployment tooling often requires extensive experience and expertise. DevOps engineers have a significant say in how the overall release process is carried out.

5. Site reliability engineers (SREs)

They have the task of monitoring applications in production before, during, and after a release. If any issues crop up, they go in as the “A-team” to troubleshoot and fix the issue.

The timelines for these fixes are based upon the agreed SLAs (Service level agreements) and SLOs (Service level objectives).

6. Security engineers

Security engineers ensure that the applications are kept secure. They are responsible for identifying and remediating any vulnerabilities in the code. A number of techniques like pen testing and vulnerability assessments, are employed. 

Above, we’ve discussed some of the more common roles when it comes to release management. Of course, no two organizations will have exactly the same roles. In smaller teams, one person multi-hats often plays the part of two or more people.

When it comes to deployments, you don’t simply slap the same templated modus operandi on all of them

Common deployment strategies

TL;DR: Deployment strategies such as big bang, rolling, blue-green, and canary are chosen based on risk, architecture, and user impact. Each approach balances speed, stability, and rollback capability.

When it comes to deployments, you don’t simply slap the same templated modus operandi on all of them. Not all releases are equal. The deployment strategy you choose depends on a few factors:

1. Risk profile and user base

Is the change going to impact a lot of people? Or just a portion of the audience? And if this change fails, will the business incur just a few hundred dollars of loss, or will it lose major functionality, causing millions of dollars in losses?

Think of an indie online game that has a few thousand players. If the release fails, it can be restored in a day, and the maximum hit would be a few hundred dollars. Compare that with software that cools a nuclear reactor. If it fails, the result could be catastrophic.

2. Architecture of the system

Does the system have a backup environment, such as BCP (business continuity planning), that takes over should something fail in production? Does the system have backup components that automatically fail over?

3. Widely-used deployment strategies

1. Big bang

One of the simplest approaches out there. The new version simply replaces the entirety of the older version. It’s fast and straightforward but carries the highest risk factor.

If the rollout becomes messy, everyone is affected. This strategy is reserved for smaller systems or changes with lower risk factors.

2. Rolling deployments

Instead of making a switch altogether, the new version is deployed gradually and incrementally across servers or containers. For example, initially, users in China might get an update. Once complete, Gulf countries get an update, then the United Kingdom, and so on.

Instead of making a switch altogether, the new version is deployed gradually and incrementally across servers or containers.

3. Blue-green deployments

Here, two identical production systems (namely blue and green) are maintained. The LIVE (blue) environment runs the current version, while deployment and validation of the new version happen on the green environment.

Once all validation has passed, the traffic is switched to the green environment. Should anything go wrong, you can always switch back to blue. This strategy allows for near-zero downtime and simple rollback ability.

4. Canary deployments

The new release is introduced to a limited set of the user base initially—let’s say 5% or 10%—before a full-blown rollout. This strategy allows dev teams to verify real-world functionality while limiting potential business loss.

Contingent on the canary faring well, the release is gradually extended to larger sets of the user base. That’s why, for example, your friends in the Netherlands might be seeing a new and improved Instagram interface a few days before you do.

Key metrics for successful release management

TL;DR: DORA metrics like deployment frequency, change failure rate, MTTR, and lead time help measure release performance. These metrics indicate speed, stability, and recovery capability.

The industry widely uses an agreed-upon set of metrics called the DORA metrics to measure mission success:

1. Deployment frequency: A measure of how often your team makes successful releases to production. Higher-performing teams have higher deployment frequencies.
2. Change failure rate: Percentage of releases that result in downtime or require a rollback to be made. Top-performing teams keep their change failure rates below 5%.
3. Mean time to recovery (MTTR): A measure of how resilient your pipelines are. You measure how quickly your team can fix a failed release and bring the application back to base.
4. Lead time for changes: The total time it takes for your team to commit code, all the way to the final deployment.

Best practices for release management

TL;DR: Effective release management relies on standardization, automation, collaboration, continuous delivery, and continuous improvement. These practices help ensure consistency and reduce errors.

Certain guidelines can help you create an effective release management plan:

1. Standardization

Develop standards that are compliant with your company’s policy and adequate for your product’s tech landscape. This helps maintain consistency across releases, making sure that all the processes are repeatable.

2. Automation

Use appropriate toolchains to automate builds, testing, deployments, and validations.

David Farley, who co-authored Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation with Jez Humble, stressed the need to avoid manual work: “Asking experts to do boring and repetitive, and yet technically demanding tasks is the most certain way of ensuring human error that we can think of, short of sleep deprivation, or inebriation.”

3. Collaboration

Cross-team collaboration is vital to executing an effective release management process. Use tools like Confluence to document releases, Slack for quick communications, and Jira for tracking and managing end-to-end tests. This helps avoid silos and improve visibility.

4. Continuous delivery (CD)

CD pipelines help ensure your releases are safely and quickly deployed to production.

5. Continuous improvement

The release manager should lead a continuous improvement mindset. Capturing what went wrong, ways to avoid it, and baking it into the standards. As a by-product, the user experience should be enhanced for all those involved.

Challenges in release management

TL;DR: Common challenges include insufficient planning, poor documentation, and unclear requirements. These issues can lead to delays, failures, and increased effort in future releases.

Insufficient planning or bad practices can plague your release management process with challenges.

1. Insufficient planning

A release might fail if the plan and associated resources are not well thought out. The vulnerabilities can pop up in various forms:

1. The testers’ availability wasn’t fully aligned, and the test window was missed. I’ve seen this happen multiple times. Nowadays, teams often operate across global locations.
   What is business as usual in one place might be a local holiday in another. Release managers should explicitly align the availability and capacities of the testers and ensure accountability if the testers do not show up.
2. The team set up the environment but had to patch it at the last minute, rendering the environment useless during the release process, so they had to stop the release.
3. The testing should have taken three days, but it eventually took two weeks due to several bugs.

Teams need to spend more time on future releases if they don’t do a good enough job of documenting their prior releases.

2. Poor documentation

Teams need to spend more time on future releases if they don’t do a good enough job of documenting their prior releases. Undocumented knowledge is lost knowledge.

People come and go. Toolchains change and evolve with time. Hence, it’s important to document the entire process in a robust repository.

As a developer, I find that documentation isn’t exactly the glorious part of the job. But it’s a necessary pain all developers need to come to terms with.

Gerald Weinberg aptly described this in his book The Psychology of Computer Programming: “Documentation is the castor oil of programming. Managers think it is good for programmers and programmers hate it!”

In any case, documentation helps save hours of sifting through code and unexpected surprises.

As a recent personal anecdote on why documentation is vital: I own a supply-chain application hosted in Azure. My ops leader reported that we had two secrets flagged by the compliance team that had expiration dates beyond the company policy.

I suggested that we simply rotate the secrets. It took the data engineer 3-4 hours to manually check if the code was even using the secret in the first place.

This would’ve been a simple task—only a few minutes—if we had prior documentation of where the code was using the secret.

The last thing a development team should be doing is creating a release, only for business to come back and tell them that it’s unacceptable

3. Unclear requirements

Document the requirements for the success criteria in detail and ensure they are clear. The last thing a development team should be doing is creating a release, only for business to come back and tell them that it’s unacceptable.

Conclusion

TL;DR: Release management is essential for delivering reliable and efficient software. Its importance will continue to grow with increasing demand for faster and more stable releases.

Release management as a practice is likely to continue evolving further. Today, it’s a necessity for software success. When development teams get it right, they’re able to improve user experience, decrease downtime, release more quickly, and drive more business success.

From here on, the importance of release management will only grow as more businesses will require faster releases and stable software for billions of people.

As a result, we will need even better release management tools. We can expect the future to see even greater automation, closer DevOps integrations, and toolchains involving AI.

Visit the Tricentis website to learn more about release management.