Understand Deployment Strategies

The architectures described in this article illustrate how to build and deploy a modern application with Blue-Green and Canary deployment strategies. Deployment strategies are models and practices that enable modification or upgrade of application. Deployment strategies allow DevOps teams to define how applications get deployed to the production environment.

Choosing between different deployment strategies allows admins to make the right trade-off between the risk of deploying a new release, the impact of the new release on its users, and the infrastructure overhead needed to implement the strategy. We want to give our customers more options to make the right trade-off given their application needs.

About Blue-Green Deployments

With a Blue-Green deployment strategy, DevOps teams want to release a new version of their application using two identical environments where one of them is active at a given time. The current version of the application is provisioned on the active environment, whereas the new version gets deployed to the standby environment.

Deploying to the standby environment does not impact the active environment or the user traffic. The DevOps release pipeline can run validation tests against the new version, and once approved, it gets promoted to production by simply switching the user traffic to the standby environment. This process will repeat for each new release of the application.

The main advantage of this strategy is that it offers near-zero downtime and instant rollback capabilities. In case of any issues with the new version, traffic can instantly revert to the previous stable version. And the standby environment is available to debug what went wrong in the application release.

This diagram illustrates a Blue-Green deployment architecture:

Description of the illustration blue-green-deployment.png

Understand Blue-Green Deployment Components

The preceding architecture has following components.

• Region

  An OCI region is a localised geographic area that contains one or more datacenters, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents). The architecture uses a single region.

• DevOps project

  A logical grouping of DevOps resources needed to implement a CI/CD workflow. DevOps resources can be artifacts, build pipelines, deployment pipelines, external connections, triggers, and environments. DevOps projects make it easy to enable logging, monitoring, and notifications for all your DevOps resources.

• Build pipeline

  A build pipeline takes a commit ID from your source code repositories and uses that source code to run your build instructions. Build pipelines defines a set of stages for the build process – building, testing and compiling software artifacts, delivering artifacts to OCI repositories, and optionally triggering a deployment.. You define the flow and instructions of your build run in the build spec file.

• Build stages

  Stages are individual actions that take place during a run of a pipeline.Various build stages mentioned here are: Managed Build Stages :A managed build stage to build and test the source code. Deliver Artifacts Stage :A stage to push the outputs of build stage to various repositories.Like container images to container repo and deployment manifest to artifact registry. Invoke Deployment :A stage to invoke a deployment pipeline once the build stages are completed ,along with parsing the exported variables from managed build stage to deployment pipeline stages.

• Code repository

  Private Git repositories hosted by the DevOps service. You can store, manage, develop source code with our DevOps Code Repositories. Deployment pipeline A sequence of steps for delivering and deploying a set of artifacts to a target environment. The flow and logic of your software release can be controlled by defining stages that can run in serial or parallel.

• Deployment stages

  Stages are individual actions that take place during a run of a pipeline. Various build stages mentioned here are:

  • Blue/Green OKE Deployment or Blue/Green Instance Group Deployment: Stage to deploy the updated code to target environments.
  • Deployment Validation: Optional stage to validate the deployments (Via functions)
  • Control: Approval: Control stage to approve the deployment to target production environment.
  • Blue/Green OKE Traffic Shift or Blue/Green Instance Group Traffic Shift: Final stage in which the production traffic will be switched to the latest deployed environment.

• DevOps artifact

  A DevOps artifact is a reference or pointer to any file, binary, package, manifest, or image that makes up your application. When creating an artifact, inform Oracle DevOps of the source location of the actual artifact. DevOps supports OCI Container Image Registry and OCI Artifact Registry repositories.

• Artifact repository

  Artifact Repository creates repositories to group similar artifacts. When the repository is created, you can upload artifacts to it. These artifacts are a collection of text files, binaries, and deployment manifests that are delivered to the target deployment environment. Each artifact has a name, which is made of its path: version. The path is a string to organize the artifacts.

• OCI Logging and Notification services

  OCI Logging service stores logs related to the deployment. The deployment runtime output and the final results of the deployment are shown as log entries. OCI Notifications service provides visibility into the latest state of the deployment project and its resources and takes any necessary action. For example, you're notified when an important event, such as a stage in a deploy pipeline waiting for approval. When you receive the notification message, you can go to DevOps deployment pipelines and approve the stage.

• Deployment environments

  An environment is a collection of a customer’s computing resources where artifacts are deployed. Environments can be a function, Compute virtual machine (VM) or bare metal instance, or an OKE cluster.The Blue Green deployment is available only with OKE cluster and Compute virtual machines.

Understand the Pros and Cons of Blue-Green Deployments

There are both pros and cons to using a Blue-Green strategy when deploying a modern application.

The pros of Blue-Green deployments are:

• Blue Green deployments enable quick and risk free deployments.
• They enables with an effective simple rollback mechanism.
• They an effective way to orchestrate A/B software testings.
• Zero or nearly zero downtime as the production is always served via one of the active environment (behind a load balancer).

The cons of Blue-Green deployments are:

• Maintaining the environment of a Blue-Green deployment requires intense cost for identical environments and resources.
• You need to closely monitor both environments to manage the release between two identical environment.
• Managing database dependencies between deployments is complicated.

About Canary Deployments

With a Canary deployment strategy, the application release happens incrementally to a subset of users. Initially, the new version gets deployed to a canary environment with no user traffic. The DevOps release pipeline can run validation tests against the new version and, once ready, route only a subset of users to the canary environment. .

This technique allows the DevOps team to evaluate the new application version against real user traffic. They can compare the two application versions side-by-side before rolling out the new version to a larger user base. It also offers risk mitigation as the new version is only enabled for a small subset of users—these users can easily switch back to the previous version in case of any issues.

The following diagram illustrates a Canary deployment strategy:

Description of the illustration canary-deployment.png

Understand Canary Deployment Components

The preceding architecture has following components.

• Region

  An OCI region is a localized geographic area that contains one or more datacenters, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents). The architecture uses a single region.

• DevOps project

  A logical grouping of DevOps resources needed to implement a CI/CD workflow. DevOps resources can be artifacts, build pipelines, deployment pipelines, external connections, triggers, and environments. DevOps projects make it easy to enable logging, monitoring, and notifications for all your DevOps resources.

• Build pipeline

  A build pipeline takes a commit ID from your source code repositories and uses that source code to run your build instructions. Build pipelines defines a set of stages for the build process – building, testing and compiling software artifacts, delivering artifacts to OCI repositories, and optionally triggering a deployment. You define the flow and instructions of your build run in the build spec file.

• Build stages

  Stages are individual actions that take place during a run of a pipeline.Various build stages mentioned here are:

  • Managed Build Stages: A managed build stage to build and test the source code.
  • Deliver Artifacts Stage: A stage to push the outputs of build stage to various repositories. Like container images to container repo and deployment manifest to artifact registry.
  • Invoke Deployment: A stage to invoke a deployment pipeline once the build stages are completed ,along with parsing the exported variables from managed build stage to deployment pipeline stages.

• Code repository

  Private Git repositories hosted by the DevOps service. You can store, manage, develop source code with our DevOps Code Repositories.

• Deployment pipeline

  A sequence of steps for delivering and deploying a set of artifacts to a target environment. The flow and logic of your software release can be controlled by defining stages that can run in serial or parallel.

• Deployment stages

  Stages are individual actions that take place during a run of a pipeline. Various build stages mentioned here are:

  • Canary OKE Deployment or Canary Instance Group Deployment: Stage to deploy the updated code to target canary environments.
  • Deployment Validation: Optional stage to validate the deployments (Via functions)
  • Canary OKE Traffic Shift or Canary Instance Group Traffic Shift: Stage to switch traffic towards canary environment based on the ramp limit (% of traffic to shift).
  • Control: Approval: Control stage to approve the deployment to target production environment.
  • Canary Deploy Instance Group Production or OKE Deploy Production: Final stage in which the production traffic will be switched to the latest deployed environment.

• DevOps artifact

  A DevOps artifact is a reference or pointer to any file, binary, package, manifest, or image that makes up your application. When creating an artifact, inform Oracle DevOps of the source location of the actual artifact. DevOps supports OCI Container Image Registry and OCI Artifact Registry repositories.

• Artifact repository

  Artifact Repository creates repositories to group similar artifacts. When the repository is created, you can upload artifacts to it. These artifacts are a collection of text files, binaries, and deployment manifests that are delivered to the target deployment environment. Each artifact has a name, which is made of its path: version. The path is a string to organize the artifacts.

• OCI Logging and Notification services

  OCI Logging service stores logs related to the deployment. The deployment runtime output and the final results of the deployment are shown as log entries. OCI Notifications service provides visibility into the latest state of the deployment project and its resources and takes any necessary action. For example, you're notified when an important event, such as a stage in a deploy pipeline waiting for approval. When you receive the notification message, you can go to DevOps deployment pipelines and approve the stage.

• Deployment environments

  An environment is a collection of a customer’s computing resources where artifacts are deployed. Environments can be a function, Compute virtual machine (VM) or bare metal instance, or an OKE cluster.The Blue Green deployment is available only with OKE cluster and Compute virtual machines.

Understand the Pros and Cons of Canary Deployments

There are both pros and cons to using a Canary strategy when deploying a modern application.

The pros of Canary deployments are:

• It enables you to test two application versions side by side with real users.
• There is zero downtime for new version release.
• The rollback to a previous version is very easy and provides the least risk.

The cons of Canary deployments are:

• The testing and validation of new release might be complex at scale.
• Fetching the feedback out of user testing against a new release is a time consuming task.