CD Pipeline

Prerequisites

After your CI pipeline is ready, you can start building your CD pipeline. Devtron enables you to design your CD pipeline in a way that fully automates your deployments. Images from Build stage can be deployed to one or more environments through dedicated CD pipelines.

Click the '+' sign on CI Pipeline to attach a CD Pipeline to it.

Figure 1: Adding CD Pipeline

A basic Create deployment pipeline window will pop up.

Figure 2: Creating CD Pipeline

Here, you get two tabs:

  • New Deployment - Use this option to create a new Helm/GitOps deployment.

  • Migrate to Devtron - Use this option if you wish to migrate your existing Helm Release/Argo CD Apps to Devtron.


New Deployment

The New Deployment tab displays the following sections:

Deploy to Environment

This section expects four inputs from you:

Setting
Description
Options

Environment

Select the environment where you want to deploy your application

(List of available environments)

Namespace

Automatically populated based on the selected environment

Not Applicable

Trigger

When to execute the deployment pipeline

Automatic: Deployment triggers automatically when a new image completes the previous stage (build pipeline or another deployment pipeline) Manual: Deployment is not initiated automatically. You can trigger deployment with a desired image.

Deployment Approach

How to deploy the application

Helm, GitOps(ArgoCD) or Gitops (FluxCD) Refer GitOps to learn more

FluxCD Deployment Failed

Deploying to an Isolated Environment?

In case you are choosing an isolated environment for deployment, you will get two additional options to choose from in the 'Deploy to Environment' window (check snapshot):

  • Do not push - A link to download the helm package will be available after the deployment. However, it will not push the helm package to the OCI registry.

  • Push to registry - This will generate and push the helm package to the OCI registry. Upon selecting this option, you will get two more fields:

    • Registry - Choose the OCI registry to which the helm chart package must be pushed. Only those registries that have Push helm packages enabled will be shown in the dropdown.

    • Repository - Enter the repository name. You can find the username from your registry provider account (e.g., Docker Hub).

Deployment Strategy

Devtron supports multiple deployment strategies depending on the deployment chart type.

Figure 3: Strategies Supported by Chart Type

Refer to Deployment Strategies to know more about each strategy in depth.

The next section is Advanced Options and it comes with additional capabilities. This option is available at the bottom of the Create deployment pipeline window. However, if you don't need them, you may proceed with a basic CD pipeline and click Create Pipeline.

Figure 4: Advanced Options

Advanced Options

After selecting Advanced Options, the Create deployment pipeline window has 3 distinct tabs, and you will see the following additions:

Figure 5: Advanced Options (Expanded View)

Note

You can create or edit a deployment strategy in Advanced Options. Remember, only the default strategy will be used for deployment, so use the SET DEFAULT button to mark your preferred strategy as default after creating it.

Pre-Deployment Stage

If your deployment requires prior actions like DB migration, code quality check (QC), etc., you can use the Pre-Deployment stage to configure such tasks. Refer Pre/Post tasks to configure tasks in Pre-Deployment stage.

Figure 6: Pre-Deployment Stage

Deployment Stage

Pipeline Name

The pipeline name will be auto-generated; however, you are free to modify the name as per your requirement.

Deployment Strategies

A deployment strategy is a method of updating, downgrading, or creating new versions of an application. The options you see under deployment strategy depend on the selected chart type (see Fig. 3). Below are some deployment configuration-based strategies.

Blue-Green Strategy

Blue-green deployments involve running two versions of an application at the same time and moving traffic from the in-production version (the green version) to the newer version (the blue version).

blueGreen:
  autoPromotionSeconds: 30
  scaleDownDelaySeconds: 30
  previewReplicaCount: 1
  autoPromotionEnabled: false
Key
Description

autoPromotionSeconds

It will make the rollout automatically promote the new ReplicaSet to active Service after this time has passed

scaleDownDelaySeconds

It is used to delay scaling down the old ReplicaSet after the active Service is switched to the new ReplicaSet

previewReplicaCount

It will indicate the number of replicas that the new version of an application should run

autoPromotionEnabled

It will make the rollout automatically promote the new ReplicaSet to the active service

Rolling Strategy

A rolling deployment slowly replaces instances of the previous version of an application with instances of the new version of the application. Rolling deployment typically waits for new pods to become ready via a readiness check before scaling down the old components. If a significant issue occurs, the rolling deployment can be aborted.

rolling:
  maxSurge: "25%"
  maxUnavailable: 1
Key
Description

maxSurge

No. of replicas allowed above the scheduled quantity

maxUnavailable

Maximum number of pods allowed to be unavailable

Canary Strategy

Canary deployments are a pattern for rolling out releases to a subset of users or servers. The idea is to first deploy the change to a small subset of servers, test it, and then roll the change out to the rest of the servers. The canary deployment serves as an early warning indicator with less impact on downtime: if the canary deployment fails, the rest of the servers aren't impacted.

canary:
  maxSurge: "25%"
  maxUnavailable: 1
  steps:
    - setWeight: 25
    - pause:
        duration: 15 # 15 sec
    - setWeight: 50
    - pause:
        duration: 1m # 1 min
    - setWeight: 75
    - pause:
        duration: 1m # 1 min
Key
Description

maxSurge

It defines the maximum number of replicas the rollout can create to move to the correct ratio set by the last setWeight

maxUnavailable

The maximum number of pods that can be unavailable during the update

setWeight

It is the required percent of pods to move to the next step

duration

It is used to set the duration to wait to move to the next step

Recreate Strategy

The recreate strategy is a dummy deployment that consists of shutting down version 'A' and then deploying version 'B' after version 'A' is turned off.

A recreate deployment incurs downtime because, for a brief period, no instances of your application are running. However, your old code and new code do not run at the same time. It terminates the old version and releases the new one.

recreate:

Unlike other strategies mentioned above, 'Recreate' strategy doesn't contain keys for you to configure.

Does your app have different requirements for different environments?

Configure Deployment Strategies

To configure the CD pipeline for different deployment strategies, follow the steps below:

  1. Select Add Strategy and select the deployment strategies you want to add.

    Figure 7: Adding Deployment Strategy
    • In case, you have multiple deployment strategies, you have to choose a default deployment strategy which are configured for the pipeline.

      Figure 8: Selecting Default Deployment Strategy
    • If in any scenario such as deploying a hotfix, if you need to use a different deployment strategy other than the default, you can change it from Build & Deploy section while triggering the deployment.

      Note: You can only select the deployment strategies which are configured for that pipeline.

      Figure 9: Selecting Deployment Strategy
  2. Configure the deployment strategy by selecting the Settings icon next to it to edit the strategy template according to your use case.

    Figure 10a: Editing Blue Green Strategy Template
    Figure 10b: Editing Blue Green Strategy Template
    Figure 10c: Editing Canary Strategy Template
    Figure 10d: Editing Blue Green Strategy Template
  3. Select Update Pipeline to save the configurations.

    Figure 11: Selecting Update Pipeline

Custom Image Tag Pattern

Note

  1. Enable the toggle button as shown below.

    Figure 12: Enabling Custom Image Tag Pattern
  2. Click the edit icon.

    Figure 13: Edit Icon
  3. You can write an alphanumeric pattern for your image tag, e.g., prod-v1.0.{x}. Here, 'x' is a mandatory variable whose value will incrementally increase with every pre or post deployment trigger (that option is also available to you). You can also define the value of 'x' for the next trigger in case you want to change it.

    Figure 14: Defining Tag Pattern

Warning

  1. Click Update Pipeline.

To know how and where this image tag would appear, refer Copy Container Image Plugin

Pull Container Image with Image Digest

Although Devtron ensures that image tags remain unique, the same cannot be said if images are pushed with the same tag to the same container registry from outside Devtron.

Therefore, to eliminate the possibility of pulling an unintended image, Devtron offers the option to pull container images using digest and image tag.

Figure 15: Pull with Image Digest

An image digest is a unique and immutable SHA-256 string returned by the container registry when you push an image. So the image referenced by the digest will never change.

Figure 16: Tag@Digest

Who Can Perform This Action?

Post-Deployment Stage

If you need to run any actions, e.g., closure of Jira ticket, load testing, or performance testing, you can configure such actions in the post-deployment stages.

Post-deployment stages are similar to Pre-Deployment stages. The difference is that pre-deployment executes before the deployment, while post-deployment occurs after.

You can use ConfigMap and Secrets in post deployments as well. The option to execute tasks in application environment is available too.

Refer Pre/Post tasks to configure tasks in Post-deployment stage.

Figure 17: Post-deployment Stage

Migrate to Devtron

When can I see this option?

This option will be available only during the creation of CD pipeline in your workflow. Existing CD pipelines will not have this option.

Who Can Perform This Action?

If you already use external Helm or Argo CD for deployment and wish to try out Devtron, this feature helps you onboard and manage your external applications using Devtron’s CI/CD capabilities, offering the following benefits:

  • No hassle of manually migrating your existing applications

  • No need to set up a parallel Argo CD instance

  • No risk of losing your existing configurations

  • Use build pipeline in your workflow

  • Execute pre-deployment and post-deployment tasks

  • Scan your apps for vulnerabilities

  • Hibernate or restart your app

  • View config diff, deployment history, and all the capabilities that come with Devtron Apps. Check the full list of features.

Migrate Helm Release

Prerequisites

You can not only view your external Helm apps, but also manage their deployments using Devtron's CI/CD.

  1. Click Helm Release in 'Select type of application to migrate'.

  2. Select the external cluster containing your Helm releases, and select the Helm release you wish to migrate.

    Figure 18: Choosing External Cluster and Helm Release from Dropdown
  3. The target cluster, its namespace, and environment would be visible. If the environment is not available, click Add Environment. This will open a new tab. Once you have added the environment to your cluster, return and click the refresh button.

    Figure 19: Adding Environment to Target
  4. Select the trigger (Automatic/Manual) and click Create Pipeline.

    Figure 20: Creating CD Pipeline for Helm Release
  5. Once the pipeline is created, you may go to Build & Deploy to trigger the pipelines. Your Helm release would be deployed using Devtron.

Limitations

This feature comes with certain mentioned limitations and expectations. If your use case doesn't fit and goes beyond, feel free to open a feature request.

  • Apps deployed using Helm + manual kubectl, kubectl, kustomize + helm are not supported.

  • By default, Devtron detects and uses app-values.yaml as the values file. If your Helm app contains multiple values files, you must consolidate it into a single app-values.yaml.

  • Once an app is onboarded to Devtron, the user should only use Devtron to manage that application and not make manual changes on that onboarded Helm release. This is because Devtron might not monitor or reconcile the manual changes you make outside Devtron.

Migrate Argo CD Application

You can not only view your external Argo CD apps, but also manage their deployments using Devtron's CI/CD.

Prerequisites

  1. Click Argo CD Application in 'Select type of application to migrate'.

  2. Select the external cluster containing your Argo apps, and select the Argo CD application you wish to migrate.

    Figure 21: Choosing External Cluster and Argo App from Dropdown
  3. The target cluster, its namespace, and environment would be visible. If the environment is not available, click Add Environment. This will open a new tab. Once you have added the environment to your cluster, return and click the refresh button.

    Figure 22: Adding Environment to Target
  4. Select the trigger (Automatic/Manual) and click Create Pipeline.

    Figure 23: Creating CD Pipeline for Argo CD App
  5. Once the pipeline is created, you may go to Build & Deploy to trigger the pipelines. Your Argo CD app would be deployed using Devtron.

Limitations

This feature comes with certain mentioned limitations and expectations. If your use case doesn't fit and goes beyond, feel free to open a feature request.

  • The Git source type should be branch HEAD.

  • The target deployment cluster’s endpoint in Devtron must be the same as the one configured in Argo CD.

  • Once onboarded to Devtron, users should manage the application only through Devtron and avoid making changes directly in Git or Argo CD. This is because Devtron might not monitor or reconcile the manual changes you make outside Devtron.

Note

Migrate Flux CD Application

You can not only view your external Flux CD apps, but also manage their deployments using Devtron's CI/CD.

Prerequisites

  1. Click Flux CD Application in 'Select type of application to migrate'.

    Figure 28: Choosing 'Flux CD Application'
  2. Select the external cluster containing your Flux apps, and select the Flux CD application you wish to migrate.

    Figure 29: Choosing External Cluster and Flux App from Dropdown
  3. The target cluster, its namespace, and environment would be visible. If the environment is not available, click Add Environment. This will open a new tab. Once you have added the environment to your cluster, return and click the refresh button.

    Figure 30: Target Environment
  4. Select the trigger (Automatic/Manual) and click Create Pipeline.

    Figure 31: Creating CD Pipeline for Flux CD App
  5. Once the pipeline is created, you may go to Build & Deploy to trigger the pipelines. Your Flux CD app would be deployed using Devtron.

Limitations

This feature comes with certain mentioned limitations and expectations. If your use case doesn't fit and goes beyond, feel free to open a feature request.

  • The Git source type should not be branch HEAD.

  • The target deployment cluster’s endpoint in Devtron must be the same as the one configured in FluxCD.

  • Once onboarded to Devtron, users should manage the application only through Devtron and avoid making changes directly in Git or FluxCD. This is because Devtron might not monitor or reconcile the manual changes you make outside Devtron.


Updating CD Pipeline

You can update the deployment stages and the deployment strategy of the CD Pipeline whenever you require it. However, you cannot change the name of a CD Pipeline or its Deployment Environment. If you want a new CD pipeline for the same environment, first delete the previous CD pipeline.

To update a CD Pipeline, go to the App Configurations section, Click on Workflow editor and then click on the CD Pipeline you want to Update.

Figure 32: Updating CD Pipeline

Make changes as needed and click on Update Pipeline to update this CD Pipeline.


Deleting CD Pipeline

If you no longer require the CD Pipeline, you can also delete the Pipeline.

To delete a CD Pipeline, go to the App Configurations and then click on the Workflow editor. Now click on the pipeline you wish to delete. A pop-up having the CD details will appear. Verify the name and the details to ensure that you are not accidentally deleting the wrong CD pipeline and then click Delete Pipeline to delete it.


Extras

Creating Sequential Pipelines

Devtron supports attaching multiple deployment pipelines to a single build pipeline, in its workflow editor. This feature lets you deploy an image first to stage, run tests and then deploy the same image to production.

Please follow the steps mentioned below to create sequential pipelines:

  1. After creating CI/build pipeline, create a CD pipeline by clicking on the + sign on CI pipeline and configure the CD pipeline as per your requirements.

  2. To add another CD Pipeline sequentially after previous one, again click on + sign on the last CD pipeline.

  3. Similarly, you can add multiple CD pipelines by clicking + sign of the last CD pipeline, each deploying in different environments.

    Figure 33: Adding Multiple CD Pipelines

Tip

Last updated

Was this helpful?