TeamCity

Understanding Continuous Deployment

Continuous deployment (CD) extends the continuous integration and continuous delivery (CI/CD) process by automatically deploying each successful code change to production.

In this article:

What is continuous deployment?

Continuous deployment takes the DevOps practice of automating build, test, and deployment steps to its logical extreme. When a code change passes every stage of the pipeline successfully, that change is automatically deployed to production without any manual intervention. Adopting continuous deployment means you can get new features to your users as fast as possible without compromising on quality.

Continuous deployment is underpinned by a mature, well-tested continuous integration and continuous delivery process:

  • Team members commit code changes in small batches regularly.
  • Each commit triggers an automated test and build process.
  • The build is then promoted through various pre-production environments for further automated testing.
  • If no issues are discovered, the new version of the software is released to users.

Once you have a robust and reliable CI/CD process in place, you can automate the final step and start deploying changes to users automatically. With continuous deployment, releasing becomes a non-event that takes place multiple times a day.

That said, continuous deployment should not be considered the end goal for all DevOps teams. If you're building apps, APIs, or installed software, your users might not want to receive updates several times a day. Continuous delivery may be a better fit in this case.

Even if you don't want a completely automated deployment pipeline, you may want to cherry-pick some of the practices and apply them to your own CI/CD processes. Let's explore exactly what continuous deployment involves and what to consider before taking the leap towards continuous everything.

Continuous deployment vs. continuous delivery

It's easy to confuse the two, but continuous deployment and continuous delivery are distinct parts of the CD side of the CI/CD pipeline. With continuous delivery, the final release to production has to be triggered manually, whereas with continuous deployment, releases are automatic as long as all previous steps have been completed successfully.

Comparing continuous deployment and continuous delivery

Continuous deployment Continuous delivery
Release model Triggered automatically each time a code change successfully completes each stage of the pipeline. Initiated manually for changes that have successfully completed each stage of the pipeline.
Frequency of releases Up to multiple times per hour (depending on team size and pipeline speed). Typically weekly or monthly, but they can be as frequent or infrequent as you like.
Best suited to Websites and web applications. Mobile apps, desktop software, and APIs. They can also be used as a stepping-stone towards continuous deployment.
Testing process Must be fully automated and very robust. Quality gates help give developers and stakeholders confidence that tests will identify any bugs. Automated testing should be used as much as possible. A less frequent release process leaves capacity for manual acceptance and exploratory testing.
Additional considerations Canary deployments and blue/green builds can minimize the impact of any issues that are released to production. Monitoring is essential to identify issues in production as early as possible. Even though releases are triggered manually, the process itself should be automatic. Options for rolling back or deploying fixes quickly still need to be considered.

Learn more about the differences with our Continuous Integration vs. Delivery vs. Deployment guide.

Making continuous deployment a reality

If your integration and deployment processes are completely manual – with code freezes, an all-hands-on-deck testing strategy, and an anxious holding of breath on release day – hourly deployments might sound like a distant fantasy.

However, the reality is that many organizations are turning to this more regular approach. From big names like Netflix, Etsy, and Amazon to smaller, lesser-known companies, many businesses are adopting a continuous deployment system to try and keep pace with the market. This method has enabled many software creators to cut their release times from weeks or months to hours.

With mounting pressure to deliver features and respond to feedback quickly, continuous deployment provides a strategy for regular releases without compromising on quality.

Implementing a continuous deployment system

As an extension of continuous integration and delivery, continuous deployment depends on a fully automated build, test, and deployment process. This approach ensures speed doesn’t come at the cost of quality. However, implementing continuous deployment effectively needs more than just a solid foundation.

Quality gates

Before you can start releasing changes without any manual involvement, you need complete confidence in your CI/CD process. In particular, you need to ensure your automated builds and automated tests are verifying your code effectively. This step is where code quality gates can help.

Quality gates specify the criteria for code to progress to the next stage of your pipeline. For some stages, you might set a simple threshold, such as requiring a 100% pass rate with 90% code coverage for unit tests. For other automated tests, you might allow a percentage of warnings but fail the step if any errors are produced. Sometimes, you may want to flag errors or warnings for manual review before failing the step.

Using automated quality gates at key stages of your pipeline gives you control and visibility of the process and a complete audit trail of the due diligence performed on each release.

Consider the release strategy

When planning how to implement a continuous deployment system, a key question to consider is how your changes will be released. Taking servers offline for each deployment will result in frequent interruptions to online services, so a rolling update strategy is often preferred. You can also make the rollout an extension of your automated testing process using canary deployments.

Canary deployments

A canary deployment limits the deployment of the updated code to a small percentage of users, who become unwitting testers in production. By monitoring user behavior and usage metrics, you can check that the new release has not introduced new failures before you roll it out more widely.

Canary confidence score

Some companies have taken automation further with a canary confidence score, which automatically compares a range of metrics against a baseline. The automated rollout only continues if the score exceeds the specified threshold. If the score is too low, the metric analysis provides a starting point for further investigation into potential issues.

Blue/green build deployment

A blue/green build deployment process is a common technique for organizations implementing a continuous deployment system. Blue/green deployments make it easier to roll back a release in the event of a problem by keeping the old code online until you're confident the changes work as expected. If required, you can also follow an initial canary deployment with a blue/green rollout.

Monitoring production metrics

Whether you're running a blue/green deployment or rolling out direct replacements, monitoring the health of the production system is essential if you want to respond quickly to bugs that have slipped through the automated testing process.

Start by identifying key metrics that indicate your system's health. These might include system health metrics, such as disk space and CPU usage, as well as usage metrics, such as the number of requests or transactions. Comparing these metrics against a healthy baseline can provide an early warning sign if things aren't behaving as they should. You can then decide whether to roll back the change or put a fix through the pipeline.

Considerations for continuous deployment

Before jumping on the continuous deployment bandwagon, take a moment to consider some of the things you’ll need to do to ensure your adoption of CD is successful.

Engage stakeholders

The software development life cycle involves more than just code changes. User research, product marketing, interaction design, documentation, commercial, legal, and support teams all have a role to play.

If you haven’t laid the groundwork with your stakeholders and engaged with them to understand what they need from the release process, moving to automated releases can make them feel like development is out of control. That can lead stakeholders to demand manual checkpoints and review stages, slowing the process down and undermining the benefits of CI/CD. At worst, the entire continuous deployment system may be rejected as a failed experiment.

Encourage collaboration

Creating a culture of collaboration is essential for continuous deployment to work well. Involving other teams throughout the development process so that their input on design, security issues, terminology, or compliance can be incorporated early on is one example of how short feedback loops make the software development life cycle more efficient.

Keep everyone informed

Just as important as inviting input is providing visibility of what is being released and when. Keep stakeholders informed automatically with the help of a CI server. Depending on your choice of continuous build deployment tool, you should be able to disseminate information via dashboards and notifications.

Use feature flags or a dedicated branch

Sometimes, visibility of what is coming is not sufficient on its own. When you’re working on a larger feature or need to control the timing of a release, simply deploying each commit to live once it has passed all tests is not ideal.

Feature flags are one option for controlling the visibility of code in production. The advantage is that the code is live, so you can monitor your software for unexpected failures.

Another approach is to use a dedicated branch and a separate pipeline that doesn’t automatically push to production, thereby combining both continuous delivery and continuous deployment to suit your needs.

Continuous deployment best practices

When done right, continuous deployment can help teams deliver changes to users more frequently while minimizing bugs. The key to this is following best practices, including using metrics to optimize your pipeline and monitoring your production environment for any signs of trouble. It's also important to recognize the cultural shift involved and get the whole team on board with the CI/CD process.

You can learn more about how to streamline your CI/CD process and obtain better results with our guide to continuous deployment best practices.

Summing up

  • Continuous deployment is a DevOps practice that automates every stage of the build, test, and release process.
  • The aim of continuous deployment is to deliver functionality to users faster and more frequently, without compromising on quality.
  • Continuous deployment is particularly suited to websites and web applications, as users do not need to apply the updates themselves.
  • Faster, more frequent releases enable rapid feedback from users and reduce the impact of any bugs that manage to slip through into production.
  • Automated tests, production monitoring, collaboration with other functions, and user behavior all provide inputs to the software development process.
  • By working in smaller chunks and releasing frequently, you can keep adjusting based on feedback and continuously improve what you deliver.

How TeamCity can help

TeamCity facilitates the process of setting up continuous deployment with highly configurable trigger options and deployment build runners. Dedicated deployment build configurations mean you can restrict permissions to deploy to production, while flexible build triggers allow you to define conditions for releasing. Use TeamCity's built-in support for package repositories and container registries to manage your build artifacts as part of your continuous deployment process.

Keep your stakeholders informed of progress by giving them access to TeamCity's intuitive, web-based dashboards. Powerful role-based access control ensures you can secure the path to production, while built-in audit trails provide a comprehensive record of all activity in your pipelines.

TeamCity UI