Using Change Cause in Azure Pipelines for Efficient Kubernetes Rollbacks

Continuous Deployment (CD) ensures your applications are always up-to-date with the latest changes. However, it’s equally important to have a robust rollback strategy to handle any issues that arise from new deployments. Incorporating the kubernetes.io/change-cause annotation with your deployments can significantly enhance your ability to manage and revert changes quickly and efficiently. This post will guide you through applying the last commit hash as the change cause during CD using Azure Pipelines.

Why Use Change Cause in Continuous Deployment?

Using the kubernetes.io/change-cause annotation during deployment has several benefits:

1. Improved Traceability: Easily trace deployments back to specific commits, which helps in debugging and auditing.
2. Enhanced Rollback Management: Quickly identify and revert to a specific revision based on meaningful descriptions.
3. Better Accountability: Understand what changes were made and who made them, improving team accountability.

Automating Change Cause in Your Azure Pipeline

To ensure every deployment includes a meaningful change cause, you can automate this process in your Azure Pipeline. Here’s how to do it:

Step 1: Define Your Pipeline

First, set up your Azure Pipeline YAML file to include the necessary steps for deploying with the change cause.

azure-pipelines.yml

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    addToPath: true

- script: |
    pip install kubernetes
  displayName: 'Install kubernetes Python package'

- script: |
    git rev-parse HEAD > commit_hash.txt
  displayName: 'Get latest commit hash'

- task: Kubernetes@1
  inputs:
    connectionType: 'Kubernetes Service Connection'
    kubernetesServiceEndpoint: '<your-kubernetes-service-connection>'
    namespace: '<namespace>'
    command: 'apply'
    arguments: '--record -f $(Pipeline.Workspace)/manifests/'
  displayName: 'Deploy to Kubernetes'

- script: |
    commit_hash=$(cat commit_hash.txt)
    kubectl annotate deployment <deployment-name> kubernetes.io/change-cause="$commit_hash" --overwrite

Step 2: Configure Service Connection

Ensure you have a Kubernetes service connection configured in your Azure DevOps project. This connection allows Azure Pipelines to communicate with your Kubernetes cluster.

Step 3: Verify Deployment and Change Cause

After deploying, verify that the change cause annotation has been correctly applied to your deployments:

kubectl describe deployment <deployment-name> -n <namespace> | grep "Change Cause"

Using Change Cause for Efficient Rollbacks

When a deployment fails, the change cause annotation helps you quickly identify and revert to a previous stable revision.

Step 1: List Deployment Revisions with Change Causes

Use the following command to list all revisions of a deployment along with their change causes:

kubectl rollout history deployment <deployment-name> -n <namespace>

Step 2: Roll Back to a Specific Revision

Choose the desired revision and roll back to it:

kubectl rollout undo deployment <deployment-name> -n <namespace> --to-revision=<revision-number>

Conclusion

By automating the inclusion of the change cause annotation in your Azure Pipeline, you enhance the traceability and manageability of your Kubernetes deployments. This practice not only improves your ability to handle rollbacks efficiently but also provides better accountability and understanding of changes. Implement this strategy to keep your Kubernetes deployments robust and your rollbacks seamless.