Deployment practices have changed considerably during the last ten years or so. We started in a world of heavily managed deployments tightly coupled to the release of new features. These deployments happened a few times per year or quarter. And then we transitioned to a world of frequent if not daily deployments.
Ideally, these deployments are only loosely coupled to the release of new features. So how has deployment management evolved? And what do you need to understand in order to ensure that deployment processes, automation, and management are providing the value that your organization needs?
In this post we’ll talk about how deployment management has changed, how the line between deployment and release management has become wider, and what you should drive in order to continue growth and improvement in this space.
Deployment Management vs Release Management
First, let’s talk about the definition of deployment management and then compare it to its old counterpart, release management.
Coupled Beginnings
To start, according to the Information Technology Infrastructure Library (ITIL), "Release and Deployment Management aims to plan, schedule, and control the movement of releases to test and live environments. The primary goal of this ITIL process ensures that the integrity of the live environment is protected and that the correct components are released." Coupling these two concepts made sense years ago. In the past, when teams deployed code to production, it also meant that they released new features at the same time.
You typically did not release new features without a deployment, and a deployment released new features upon completion. The two were intertwined. However, they don't have to move together. Let's consider this further.
Diverging Deployments and Releases
For deployment management, you focus on the deployment of new code into an environment. And for release management, you manage the release of new features and bug fixes. Though both might seem the same, more and more when we deploy new versions into production, it does not mean that we deploy new features at the same time.
In fact, by decoupling the deployment of code with the release of new features, we gain control over who uses what code and when. For example, if I deploy code today that contains a new feature, I oftentimes hide that feature using a feature flag.
That means that I can deploy at any time and don’t have to time deployments with promotional releases or marketing calendars. Then, when I want to activate my new feature, I enable the feature flag to roll that feature out to some or all of my customers. And if problems occur, oftentimes I can roll back the feature without deploying anything additional to production.
So, release management is about managing the release of new features and products to best meet customer, marketing, and risk constraints. Meanwhile, deployment management is about managing the deployment of code to environments. And though these concepts lived together in the past, separating them will drive modern deployment practices and advantages.
Modern Deployment Management
Next, let's talk about what modern deployment management entails. With modern tools and practices, when we trigger the deployment process, we expect several things to occur.
1. Tests execute against the code.
2. Additional quality checks like linting and SAST validate best practices and security.
3. Code builds and deploys in a consistent manner.
4. Environment-specific properties and secrets are applied.
5. Auditing and governance concerns log the necessary data automatically.
6. We know what version of the code is running in each environment and when versions are deployed.
7. The deployment process and tools allow for quick reverts of changes or fast emergency deploys in case of issues.
Deployment Strategies
Along with deployment management, we require the use of modern deployment strategies that allow for improved consistency, availability, and zero to minimal downtime. In this section we'll cover a few common deployment strategies.
As you've probably experienced, teams and organizations can use various deployment strategies when deploying code. However, whichever one you choose, the strategy should provide automation, auditability, and observability, fulfilling the expectations we laid out in the previous section. The most common strategies include the following:
- Blue/Green. Allows for zero downtime deployments by creating duplicate instances of the previous (blue) version deployed, then traffic is switched over to the new deployment (green) once it’s ready.
- Canary. Deploying instances for a small set of users for monitoring or testing before rolling out across all production instances.
- Rolling. Deploying gradually over all instances in production.
When a developer pushes code or merges a PR, the deployment strategy should minimize or prevent downtime while also allowing for processes and people to validate the deployment.
Development Practices That Support Modern Deployment Management
In general, development teams should deploy code frequently. Now, this doesn’t mean that your customers or integrations need to support constantly changing product. In order to have a manageable product, keep the following in mind: Developers should deploy to production often.
Depending on the size of your team and other development practices, this could be weekly, daily, or continuous deployments to production. To enable those frequent deployments, utilize modern CI/CD pipelines and tools like Jenkins, GitHub Actions, or Octopus.
These tools also allow you to have visibility into what's going on in your environments. For example, you can integrate your pipelines with OpsLevel to provide relevant deployment data right in your microservice catalog. In order to separate deployments from enabling and disabling features, development teams use feature flags and other practices to ensure that new features can be rolled out gradually.
Utilizing feature flags also allows you to roll back features without requiring another deployment. And finally, to support consumers of your APIs, your API versioning strategy needs review. The versioning strategy should include periodic deployments with change logs that external development teams can utilize to move to the next version of your APIs.
Enabling Visibility of Deployments
Earlier we mentioned that you should have visibility into what version of code is running in each of your environments. Though this is something that organizations often try to build themselves, many features within OpsLevel's microservice catalog enables that view.
To ensure that you have a holistic view of what's deployed for each service, you can track deploys to your environments. And when monitoring or investigating changes in metrics related to the performance of your product, you can validate whether a recent deployment could have caused problems by checking to see if there's been a recent deployment.
Summary
We tracked modern deployment management develop through advancements in automation, observability, and ultimately the decoupling of releases and deployments. As you work to ensure your organization adheres to this paradigm, the right tools and support will drive you in the right direction. To speed up adoption, consider if OpsLevel can provide a head start on your deployment management.
This post was written by Sylvia Fronczak. Sylvia is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.