When it comes to software development, businesses today often face two big challenges: shipping software fast and innovating at scale. DevOps seeks to help solve these problems by applying automation throughout the software development lifecycle (SDLC) to facilitate the quick delivery of more reliable and secure software.

Continuous deployment, or CD, is one of the more advanced examples of automation in a DevOps practice. It requires a mixture of rigorous testing, deep cross-team collaboration, advanced tooling, and workflow processes across the application design and development process.

And when it’s successfully implemented, it works. DevOps organizations that adopt CD have been found to ship code faster and outperform other companies by 4-5x.

In this guide, we’ll explore:

• The benefits of continuous deployment

• The continuous deployment process

• The difference between continuous delivery and continuous deployment

• Continuous deployment pipelines explained

• A continuous deployment pipeline model

• How to make continuous deployment work in your organization

The benefits of continuous deployment

When successfully implemented, continuous deployment makes it easier for businesses to quickly respond to customer demands and ship software updates at a rapid clip—often within minutes committing code changes.

Still, implementing CD can be a radical shift from spending days, or even weeks preparing for a software release. But businesses that make the investment in time, resources, and tooling see concrete advantages.

Some common benefits include:

• Fully automated deployment cycles. This enables organizations to spend more time building software instead of pausing development work in preparation for “release day.”

• More regular, incremental deployments. This leads to faster product development work and helps facilitate a continuous improvement model.

• Fast feedback loops on new features. Organizations can quickly get real-time feedback on new features, updates, and code changes.

What is the continuous deployment process?

Pro tip: This guide assumes you understand continuous integration and the concept of automated pipelines. If you're unclear on these DevOps practices, try reading our guide.

DevOps seeks to increase the speed of innovation and value delivery by applying automation to every stage of the SDLC. With that view, continuous deployment stands as the ultimate goal of DevOps: A completely automated SDLC where every code change is pushed to production if it passes a predefined set of tests.

In some ways, building an automated pipeline is one of the easiest parts of adopting a continuous deployment model. But very few organizations start their DevOps journey by building a continuous deployment practice due to the cultural change it signifies, and the maturity of the testing suite it requires.

In that light, it’s best to understand the process and journey it takes to achieve a fully functioning continuous deployment practice.

The graphic below shows a high-level journey map for how organizations typically start thinking about automating the SDLC.

To start, organizations need to build a continuous integration (CI) practice. The foundational elements of a strong CI practice—regular code commits, a testing strategy, version control tooling, and a CI platform—set the stage for organizations to begin developing a continuous deployment practice.

At its most basic, continuous deployment brings automated builds, tests, and deployments together in a single release workflow. The goal is to automate the deployment of software builds into production. Each company needs to identify the right combination of unit, functional, and stress tests that comprise its testing suite. It’s also critical to mirror production environment pressures in a pre-production environment to effectively stage and test builds and release candidates.

Getting all of this right leads to a significant payoff: faster and more stable releases. It also positions organizations to achieve continuous deployment with a fully automated CI/CD pipeline.

Ideally, a DevOps practice becomes so fine-tuned across its testing regimen, automation triggers, workflow composition, and CI/CD platforms that it naturally leads to continuous deployment. In effect, the need for human intervention to orchestrate a software release dissipates over time.

In practice, however, achieving a durable and scalable continuous deployment model takes significant investments in engineering resources and tooling. And while CI/CD platforms and associated tooling go a long way to standing up a continuous deployment practice, a cultural change that emphasizes cross-team collaboration and regular code commits is critical.

What is the difference between continuous delivery and continuous deployment?

Continuous delivery and continuous deployment are two DevOps automation practices that are often confused with one another—which isn't helped by the fact they're both often abbreviated as CD and handle similar responsibilities.

But where continuous deployment applies automation to the entire release process, continuous delivery automates everything up to the deployment, or release, itself. At this point, human intervention is required to stage the deployment.

Put more simply, delivery comes before deployment.

A helpful way to think about the difference between continuous delivery and continuous deployment is what each does. In a continuous delivery practice, software is built in a way where it can be manually released at any time. Automation is used to ensure code changes are reviewed, merged, tested, packaged, and moved to a production environment so the software is ready to be shipped to customers.

In contrast, continuous deployment automates the entire process including the release of the software itself. If code changes are successfully merged and pass all predefined, automated tests, it is immediately shipped to customers.

In many ways, continuous deployment is a natural evolution of continuous delivery. If a continuous delivery pipeline is set up correctly and designed to test all elements of a software build before release, the need for someone to manually release the software to customers lessens over time.

Continuous deployment pipelines explained

A continuous deployment pipeline is an automated workflow that brings together builds, tests, and deployments to push code changes to production. Each step in the workflow produces an output that provides an input for the next step. Automated testing and monitoring take place throughout a continuous deployment pipeline to catch any potential errors, functional problems, and bugs. This provides real-time alerts and prevents any potential issues from making it into the main software branch, or into production.

The end result? Engineering teams can push code changes to the main branch and quickly see it being used in production, often within minutes. This approach to software development underscores the primary goal of DevOps: continuous value delivery to end users. It’s also a central reason why many of the applications and web-based services we use regularly get new features and system changes.

Let’s explore what a continuous deployment pipeline looks like in practice.

A continuous deployment pipeline model

First, a note: There is no singular “model” for continuous deployment. Every organization will build a continuous deployment pipeline unique to their needs, software development practices, and customer demands.

Despite this, there are four commonly accepted stages in any continuous deployment pipeline that every organization should build into their engineering plans. These include:

Verification

Continuous deployment builds upon continuous integration—and it’s at this stage that CI stops, and CD begins. After a new piece of code is committed and integrated into the codebase, this triggers the automated verification process that runs a series of tests on a release candidate build. This can include functional, integration, security, and production-level testing to ensure a release candidate will work following deployment.

Common verification practices

• Automated testing: A series of predefined tests that range from functional testing to integration and acceptance testing.

• Non-functional requirement testing: Security and performance testing, among other things as required by an organization's needs, are often run prior to deployment.

Deployment

Once code is verified via testing, the automated deployment process begins. More advanced implementations will typically create automation workflows that move code to deployment immediately after it is committed (of course, this assumes it passes all predefined tests in the CI stage).

Common deployment practices

• Automated deployments: Automating code deployments after a build passes also predefined tests.

• Version control: Tracks the history of changes as people and teams collaborate on software projects together.

• Blue/green deployments: Allows for a deployment where the system gradually moves user traffic from an old version of an application to a new one.

• Production testing: Automated quality and functional tests are applied to a build after deployment to ensure production stability.

• Dark launch: Releasing code changes to a small set of users to see real-time usage and system demands before orchestrating a large-scale release.

Monitoring

Continuous monitoring is a critical element organizations need to invest in to support continuous deployment. Monitoring should take place across the SDLC. But the ability to see what is and is not working and receive real-time alerts before, during, and after deployments is key. Tooling that helps teams visualize performance metrics and show system strains are one helpful investment.

Common monitoring practices

• Application monitoring: Monitor application health with key focus areas including uptime, API responses, and stability of the front- and back-ends.

• Infrastructure monitoring: Monitor real-time system demands and how the core infrastructure is supporting those demands.

• User-behavior monitoring: Track user behavior within an application to track possible production-level system errors or elements that disrupt the user experience. This monitoring can also be used to inform future application development.

• Security monitoring: Tracking activity from malicious actors as well as any security vulnerabilities that appear in production code.

Response

Whether it’s addressing a production-level system error or identifying a security incident or potential new feature for development, being able to respond to events is a critical element of a continuous deployment pipeline. A benefit of continuous deployment is that code is immediately released into production. This also means that organizations need to be prepared to respond to and address any issues that emerge after deployment. Common metrics used to evaluate response times include MTTR (mean time to resolution), which organizations will track to evaluate improvement over time.

Common response practices

• Deployment rollbacks: Roll back an application to a previous build to solve any issues that appear in a new release.

• Infrastructure checks: Putting controls in place to keep any production-level configuration or environment changes from happening after a deployment.

• Activity logs: Maintain activity logs to help recreate user behaviors and process executions to help teams isolate potential problems.

Continuous deployment stages and environments

In order to build a scalable CI/CD pipeline, most organizations will invest resources in developing a build server to facilitate CI to compile and test code. This will typically be paired with continuous deployment pre-production and production environments.

The purpose of pre-production and production environments is to facilitate the testing and deployment of release candidates via an automated workflow. As releases make it to pre-production environments, different automated tests are applied to the codebase to identify any issues or reasons to pause a deployment.

This process typically happens in four steps:

1. Code changes are committed to a shared repository. This triggers an automated build on a CI server where dependencies are resolved, units tests are applied, and the code is packaged and compiled.

2. A release is deployed to a pre-production environment. If the code passes all tests in the CI server, it triggers an automated workflow that sends a release candidate to a continuous deployment server.

3. More automated tests are performed. With the release in a pre-production environment, additional tests will then be performed that include functional testing, security testing, performance testing, and more before a deployment is released to production.

4. A software update is released to users. Once a release candidate passes all automated tests in the developer and testing environments, it is released to end users.

The best CD environments combine rigorous testing with continuous monitoring and alerts to help teams resolve any issues quickly. While every CD environment and testing regimen are unique to the organization that develops them, they’re all united by a simple goal: continuous and fast value delivery to end users.

How to make continuous deployment work in your organization

As one of the more advanced examples of DevOps automation, continuous deployment requires time, engineering resources, and tooling to successfully adopt. It also requires a strong DevOps culture that emphasizes strong collaboration across all stages of the SDLC.

At GitHub, we know there is no singular model for continuous deployment. Every organization needs to build a practice that meets its needs and serves its business priorities. Even still, we see common best practices among all elite DevOps organizations that successfully adopt continuous deployment. These include:

• Focus on continuous integration first. A strong CI practice is foundational to building a successful continuous deployment practice and pipeline. This includes embracing a CI culture where every developer commits code changes multiple times a day. It also involves building out a strong automated testing strategy that ensures all code commits are screened before making it to production. Organizations should focus on automating as much of the SDLC as possible and keeping the main code branch green, or free from any potential issues. At GitHub, for instance, we have invested in building out our own CI/CD capabilities with GitHub Actions to have both a rich managed or self-hosted experience for organizations.

• Build a strong testing strategy. A continuous deployment practice means you’ll be releasing code changes as you make them—and any issues that aren’t caught by a test will make it into production. This makes it critical to develop a strong automated testing strategy that covers a large portion of your codebase. Most organizations aim to have at least 75% testing coverage. You’ll also want to spend time making sure your tests—be they unit, functional, performance, application, or security tests—are effective. It’s one thing to have large test coverage. It’s another thing to have good tests that make your codebase stronger, and ensure that you have confidence in your production code.

• Invest in a continuous monitoring practice. A strong testing suite and good testing coverage are critical in a continuous deployment practice. But without real-time monitoring in your testing and production environments, you’re at risk of missing the mark. A code change or new feature may introduce unintended issues your tests uncover before a deployment. And even if your tests show your codebase is stable, infrastructure issues may crop up in production when user activity introduces unexpected variables. This is why it’s critical to invest in continuous monitoring tooling to track real-time demands, system performance, and application behaviors. The best tools will help you track application and system performance as well as security issues and any irregularities in your systems. They’ll also provide you with real-time alerts and activity logs, so your engineering teams can work on potential fixes.

• Develop new tests as you develop new code. With every code change moving to production, a continuous deployment practice means you have less time to write new tests to verify them. This is a departure from other development methodologies, which typically leave more time for QA teams to work after developers have written new code and introduced new features. To solve this, it’s a good practice to develop tests as you develop new code. It’s even better if you can start thinking about your testing strategy as your product teams plan out new features. Building testing requirements into the planning and development stage is a good practice with continuous deployment. It will also have long-term benefits, as you increase your testing coverage in parallel with your product development work.

• Shift left and emphasize security across the SDLC. Security is a critical component in software today—and that’s especially true for organizations that embrace a continuous deployment practice where every code commit that passes all tests immediately makes it into production. DevSecOps is an evolution, or natural progression, of DevOps, and seeks to build security into every part of the SDLC. This means making security as early a part of the SDLC as possible—or shift lift—to ensure organizations are prioritizing the development of tests, searching out possible vulnerabilities, and strengthening systems as much as possible. A combination of tooling such as GitHub Advanced Security and cultural practices that encourage everyone to approach development with a security mindset is key. Other tools such as cloud IDEs (integrated development environments) can also be helpful to ensure your development environments are secure.

  Our philosophy is to build automation and great DevOps for the company you will be tomorrow.