Introduction to release management and deployments
The stakes are always high. Any time the IT team releases a new solution or functionality, there is the possibility of breaking services, introducing new bugs, or causing an outage. These problems negatively impact customers and often result in lost time and money for the business. A poorly planned release can wreak havoc.
This is why you need a defined release management process as part of your IT planning. Keep in mind that deployment represents just one phase of the release management process. You also need guidelines in place for planning, designing, coordinating, and testing the release before it is deployed in an operational environment.
Release management is a highly technical subject — one that we will only scratch the surface of in this guide. Releases also vary greatly depending on your organization and its IT maturity. In some organizations, the development team is responsible for building solutions and the operations team manages releases. In organizations that have adopted DevOps, a self-service model may allow development teams to automate and run their own releases. In either case, most IT teams have room to improve their release processes to increase reliability, speed, and scale.
Feel free to skip ahead to any section:
Deployment vs. release vs. delivery
The terms "deployment," "release," and "delivery" are sometimes used interchangeably. As a member of the IT team, you know these terms are different. It is important that you clarify the differences to other teams and encourage everyone to use agreed-upon language.
Here is a simple breakdown of the most common terms:
Deployment | The roll-out of new features, upgrades, or changes from one deployment environment to another. For example, you can deploy from a development environment to a staging environment. Or from a staging environment to a production environment. |
Release | Features or code that deliver a new customer experience. For IT teams, a release coincides with version tagging and a code freeze. Release can also refer to the entire release management process. In product management, a release often refers to the date when you are ready to deliver the new experience and support every customer interaction point associated with it. |
Delivery | The entire cycle of work that is done from planning to production. Also called the systems development life cycle (SDLC). |
Deployment types
Products, software, systems, infrastructure, and applications can all be deployed. Traditionally, software was deployed on-premises by installing changes on the local server or user stations. Software deployments these days typically take place in the cloud — referred to as software as a service (SaaS). Software is hosted on external servers and accessible over the internet, with access to ongoing updates released by the service provider.
Before the as-a-service deployment model, organizations had to purchase costly hardware and manage labor-intensive deployment processes. This is still the case in some organizations. However, virtual hardware can now be deployed based on the as-a-service model. Hardware as a service (HaaS), infrastructure as a service (IaaS), and platform as a service (PaaS) have fundamentally changed release management — allowing for greater speed and reduced costs.
Deployment approaches
The goal of any deployment is to release changes that run as expected in production. You want to do this in a way that is efficient, flexible, and affordable. A classic deployment flow looks like the diagram below, where technology is first deployed locally to a developer's workspace environment, then to a centralized development environment. Next, it is deployed to a staging environment before going live.
Organizations with complex infrastructure and interdependencies (as well as multiple deployments happening in parallel) typically introduce more steps in their deployment process. It is not uncommon to have multiple testing environments for integration testing and user acceptance testing.
More organizations are embracing automation and DevOps practices to improve deployments. Operations teams are increasingly choosing to automate IT changes using reusable code, much like developers do when versioning and delivering software changes. This evolution has led to infrastructure as code (IaC) and architecture as code (AaC) — where all parts of a system are designed, tested, and deployed as code.
As part of the everything-as-code model, modern approaches to deployment include:
Continuous integration: New code is automatically tested for quality before getting integrated into a shared development repository.
Continuous delivery: More automated tests are applied before code is released to production.
Continuous deployment: Usually refers to the automation of the delivery process, so that code is released to production automatically after passing the applicable tests.
Of course, deployments are just one segment in a much larger release management process. IT teams need to define processes for the entire release cycle.
Steps in the release management process
The diagram below shows a simplified release cycle, from planning to successful deployment. Different contexts dictate different practices. For example, most teams will have more robust processes in place for brand new features, whereas a bug fix may be automatically deployed via a pull request. The processes and methods that govern the release process are tightly coupled with an organization's change management processes.
The basic steps in the release cycle include:
Planning | The full release is planned — its scope, requirements, and timelines. You may choose to create a release checklist or a roadmap that visualizes key milestones and dependencies. One of the common methods for release planning is the systems development life cycle (SDLC). |
Building | In this phase, engineers design and develop the new solution, and the code is aggregated into a build. The build is deployed to testing environments. |
Testing | Depending on the type of changes, tests may be simple or more in-depth. These tests validate the change or code readiness. |
Preparing | At this stage, the last preparations for the release are made with the quality assurance (QA) team managing final checks. |
Deploying | Changes are released into production. |
The release management steps may sound straightforward. But the details are anything but simple. And it is not just about managing the technical aspects of a release either. The entire process impacts the IT team's quality of life at work.
A defined release management process brings greater stability and predictability — allowing the team to release updates, changes, and new features on schedule. And successful deployments help the business deliver new customer experiences that delight.
Best practices are best supported with the right tools. IT roadmapping software can help you manage projects, releases, and changes. Get started with Aha! Roadmaps — free for 30 days.
