> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-concepts.md).
# Deployment concepts and strategies
This topic describes common deployment strategies.
You have likely heard terms like Blue-Green and canary when it comes to deploying code and applications into production. These are common deployment strategies available in Harness CD as stage strategies, among others.
This topic explains these strategies to give you an idea of how to approach deployments in Harness and help you decide which strategy is best for you.
## What you will learn from this topic
* Review the [deployment strategies video](#deployment-strategies-video) overview
* How to decide whether to [deploy with or without gates](#deploy-with-or-without-gates)
* How Harness implements [rolling](#rolling-deployment), [Blue-Green](#blue-green-deployment), [Canary](#canary-deployment), [Build](#build-deployments), [Basic](#basic-deployments), and [multi-service](#multi-service-deployments) deployments
* How to decide [which deployment strategy to use](#which-deployment-strategy-should-i-use)
### Deployment strategies video
{% embed url="" %}
### Deploy with or without gates
CD deployments are typically performed with manual approvals before changes are deployed to production. These approvals are often referred to as approval or release gates.
Gates are checkpoints in the deployment process that can provide several benefits, including increased control, improved quality, compliance and security, stakeholder involvement, and better risk management.
However, gates can also slow down the deployment process, requiring manual intervention and increasing the time it takes to get changes to production.
CD deployments without gates, also known as "no-gate CD," are CD processes that do not require manual approval before deploying changes to production.
This approach has several advantages, including faster time to market and increased collaboration.
Of course, no-gate CD is not appropriate for all organizations and situations, and it may require significant investment in automation and testing so that changes are deployed safely and reliably.
Harness supports gated and no-gate CD by default. You can use several approval stages or steps in your pipelines, or deploy without gates.
For information on approval stages and steps, go to:
* [Using manual Harness approval stages](https://developer.harness.io/harness-platform/use-harness-platform/approvals/adding-harness-approval-stages)
* [Adding Jira approval stages and steps](https://developer.harness.io/harness-platform/use-harness-platform/approvals/adding-jira-approval-stages)
* [Adding ServiceNow approval steps and stages](https://developer.harness.io/harness-platform/use-harness-platform/approvals/service-now-approvals)
### Rolling deployment
With a rolling deployment, all nodes within a single environment are replaced one by one serially or in N batches (as defined by a window size) with a new service/artifact version.
### When to use rolling deployments
Consider a rolling deployment in the following scenarios:
* Balancing speed and safety. Nodes are replaced in an immediate series.
* Ramping load balancing scenarios that require reduced downtime.
One use of rolling deployments is as the stage preceding a canary deployment in a deployment pipeline. For example, in the first stage, you can perform a rolling deployment to a QA environment. Once the deployment succeeds, you can perform a canary deployment to production incrementally.
**Pros**
* Introduces an automatic incremental deployment; less risk than Basic deployment.
* Does not require additional infrastructure, such as a Blue-Green deployment.
**Cons**
* Verification gates between nodes are difficult to implement since a rolling deployment is designed to be executed serially.
* App/DB needs to support both new and old artifacts. Manual checks/verification at each increment could take a long time.
* Draining, lost transactions, and logged-off users are also risks to consider with any deployment type for stateful apps.
For more information, see [Create a Kubernetes Rolling Deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-rolling-deployment.md).
### Blue-Green deployment
With Blue-Green deployment, two identical environments for staging and production traffic run simultaneously with different versions of the service.
QA and User Acceptance Testing (UAT) are typically done on the stage environment. When satisfied, traffic is flipped (via a load balancer) from the production environment (current version) to the stage environment (new version).
You can then decommission the old environment once deployment is successful.
Some vendors refer to this as a red/black deployment.
### When to use Blue-Green deployments
Consider a Blue-Green deployment in the following scenarios:
* When you want to perform verification in a full production environment.
* When you want zero downtime.
**Pros**
* Simple, fast, well understood, and easy to implement: the switch is almost instantaneous.
* Less risk relative to other deployment strategies.
* Rapid rollback (flip traffic back to the old environment)
**Cons**
* Replicating a production environment can be complex and expensive (i.e., microservice downstream dependencies and infrastructure).
* QA/UAT test coverage may not identify all anomalies & regressions in the blue environment.
* An outage or SPOF could have a wide-scale business impact before rollback kicks in.
* Current transactions and sessions will be lost due to the physical switch from one machine serving traffic to another.
* Database compatibility (schema changes, backward compatibility), which is a risk with any deployment type for stateful apps.
For more information, see:
* [Create a Kubernetes Blue-Green Deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-blue-green-deployment.md)
### Canary deployment
With Canary Deployment, all nodes in a single environment are incrementally updated in small phases, with each phase requiring verification/gating to proceed to the next.
### When to use Canary deployments
When you want to verify whether the new version of the application is working correctly in your production environment.
This is the most common way to deploy apps/services into production.
**Pros**
* Deploy in small phases (e.g. 2%, 10%, 25%, 50%, 75%, 100%).
* Lowest risk among all deployment strategies (reduces business exposure).
* Test in production with real users & use cases.
* Run & compare two service versions side by side.
* Cheaper than Blue-Green because there is no need for two production environments.
* Fast and safe rollback.
**Cons**
* Scripting canary deployments can be complex (Harness automates this process).
* Manual verification can take time (Harness automates this process with Continuous Verification).
* Required monitoring and instrumentation for testing in production (APM, Log, Infra, End User, etc).
* Database compatibility (schema changes, backward compatibility), which is a risk with any deployment type for stateful apps.
For Kubernetes, Harness does this a little differently.
In Phase 1, Harness deploys a canary to the same group while leaving the production version alone, using other instances only. Harness then deletes the canary version in Phase 1.
In Phase 2, Harness performs a rolling deployment with the production version and scales down the older version.
For more information, see:
* [Create a Kubernetes Canary Deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-canary-deployment.md)
### Build deployments
A Build deployment runs a build process, such as a Jenkins job that creates a WAR file and deposits it in a registry.
{% hint style="info" %}
Build deployments in CD stages are not part of Harness Continuous Integration (CI). Harness CI performs extensive code testing, compiling, and artifact registration.
Building deployments in CD stages allows you to run standard job runs without using Harness CI. For example, go to [Run Jenkins jobs in CD pipelines](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/builds/run-jenkins-jobs-in-cd-pipelines.md).
{% endhint %}
### When to use build deployments
Typically, you use build deployments as part of a build step or stage in a CD pipeline.
A build step runs a build process (a Jenkins job) and deposits the built artifact into a registry.
**Build step for push events**
Build steps can also be used to build an artifact when the source has been updated.
For example, you might use a trigger to execute the CD pipeline in response to a Webhook event, such as a Git push. In this case, the new artifact version needs to be built before the pipeline can pick it up.
You add a build step at the beginning of the pipeline to produce the artifact, ensuring you always have the latest build.
### Basic deployments
With basic deployments, all nodes (pods, instances, etc) within a single environment are updated at the same time with a single new service/artifact version.
Basic deployments are supported in Harness for a number of platforms, allowing you to experiment with them. They are not intended for production deployments because they are less safe than Canary or Blue-Green deployments.
### When to use basic deployments
Consider a basic deployment in the following scenarios:
* Your app/service is not business, mission, or revenue-critical.
* You are deploying off-hours, and no one is using the app/service.
* You are experimenting with deployments, and it is okay if the app/service fails.
**Pros**
* Simple and fast
* Useful for learning Harness
**Cons**
* Risk, outages, and slower rollback
Not too long ago, basic deployments were how developers rolled out applications. Typically, someone in Ops updated the servers at midnight, and then you hoped all went well.
### Multi-service deployments
In multi-service deployments, all nodes in a single environment are updated simultaneously with *multiple* new services/artifacts.
For a detailed explanation of multi-service and multi-environment deployments, go to [Use multiple services and environments in a deployment](/continuous-delivery/use-continuous-delivery/cd-building-blocks/advanced/multiserv-multienv.md).
### When to use multi-service deployments
Consider a multi-service deployment in the following scenario:
* When your app has service/version dependencies.
**Pros**
* Simple, fast, and with less risk than Basic deployment.
**Cons**
* Risk
* Difficult to test/verify all service dependencies, outages, and slow rollback.
### Choose the right deployment strategy
It depends entirely on the type of application/service and environment. Most Harness customers use Blue-Green or canary deployments for mission-critical applications.
In many cases, customers are migrating from Blue-Green to Canary to test in production with minimal business impact.
You can also combine many of the above deployment strategies into a single strategy.
### FAQs
For frequently asked questions about the execution strategies supported by Harness, go to [Deployment strategies FAQs](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-faqs.md).
## Next steps
* Go to [Create a Kubernetes Rolling Deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-rolling-deployment.md) to configure a rolling deployment.
* Go to [Create a Kubernetes Blue-Green Deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-blue-green-deployment.md) to configure a Blue-Green deployment.
* Go to [Create a Kubernetes Canary Deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-canary-deployment.md) to configure a Canary deployment.
* Go to [Deployment strategies FAQs](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-faqs.md) for common questions about deployment strategies.
{% @harness-feedback/feedback %}