Skip to main content

CI-CD-Pipeline-use-guide

Introduction​

This runbook serves as a comprehensive guide for app developers (Digital Product Team) on utilizing the newly established CI/CD pipelines made by the platform team. It outlines the process from code development, through Continuous Integration (CI) in GitLab, to Continuous Deployment (CD) with FluxCD, and finally, deployment across various environments.

Tags​

Throughout the document, you will encounter the following tags appended to actions:

  • - A (for automatic) Indicates that no input is required.
  • - M (for manual) Indicates that an input from user is required.

Tools Required​

  • GitLab account with appropriate access to application group repository
  • Access to the <name-of-app>-deploy repository

Overview of the CI/CD Process​

The CI/CD process involves building, testing, tagging, and deploying application images, followed by updating the helm chart in the <name-of-app>-deployrepository to trigger deployments across cluster environments via FluxCD.

Continuous Integration (CI) Pipeline​

  1. Build and Test: Commit your code changes to trigger the CI pipeline in GitLab, which builds and tests your application. - M
    1. Manual - Merge your branch, or commit your code directly into, the "main" release branch
  2. Tag and Deploy: Upon successful build and test, the pipeline tags and pushes the application image to the GitLab repo registry. - A
  3. Trigger Downstream Pipeline: The tagging automatically triggers a downstream pipeline that updates the helm chart in the <name-of-app>-deploy repo with the new image URL. - A

​

Continuous Deployment (CD) with FluxCD​

  1. FluxCD Monitoring: FluxCD monitors the -deploy repository for changes to the helm chart. - A
  2. Dev Deployment: Once the helm chart is updated, FluxCD re-deploys the helm release in the development cluster. - A
  3. Verification: Verify the deployment in the development environment is successful. - M

    1. Manual - Run your team's test in the relevant environment and sign off on functional deployment per usual business process

Promoting Changes Through Environments​

Promote to QA - M​

After the main repository pipeline is completed, a new pipeline will be triggered in the -deploy repo with two stages:

  1. deploy:qa: This job will copy the new image URL from the /dev/values.yaml folder to /qa/values.yaml to deploy the new version of the application to the QA cluster.
    1. Manual - You need to click on the manual trigger button ("Play" button) to trigger this action
    2. Manual - The job will create a new branch with the changes and a merge request that you will need to approve to get the changes into the -deploy main branch.
  2. rollback:dev: This job will change the image URL of the current environment to the previous one used. (e.g. If you have already deployed to dev environment but the new image is not working, then you can use this job to use the latest image that was working).

    1. Manual - You need to click on the manual trigger button ("Play" button) to trigger this action

Staging and Production - M​

Repeat the promotion process for staging (stg) and production (prod) environments, using the respective pipelines to promote to the next environment or rollback.

Best Practices and Troubleshooting​

  • Pipeline Monitoring: Regularly check pipeline statuses on the main app repository and logs for errors.
  • Rollback Readiness: Be prepared to initiate a rollback if an issue is detected post-deployment in the -deploy repo.
  • Configuration Changes: to update environment variables or resource requests and limits by hand (rather than through the pipeline), see How-To: Update Application Values in Your -deploy Repository.
  • How to deploy a hotfix/release branch: - M
    • Manual Copy the .gitlab-ci.yaml file from the main branch into your feature branch and follow steps from Continuous Integration (CI) Pipeline and Promoting Changes Through Environments sections.