Comment on page
Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.
Top three reasons:
- Lower risk of changes - By delivering smaller changes to production and exercising the deployment process many times a day, we significantly lower the risk of quality regression or unexpected deployment hurdles.
- Faster time-to-market - We often have emergency applications that need to get deployed in production under quite tight deadlines. Having a safe delivery pipeline makes this possible.
- Higher quality - by running our ever-growing regression test suites after every change in the code, we make sure we do not take a step backwards quality-wise.
CI is an integral part of the CD. It ensures the quality of the code and packages the assets, making them ready for deployment.
We trigger the CI process for all GitHub Pull Requests targeting the
mainbranch without publishing assets. We trigger the CI process and publish the assets when making changes to
We lint the code, check the formatting of the code, perform Node modules vulnerability scan, run the unit and integration tests, run the end-to-end tests (results recorded to cypress.io: https://dashboard.cypress.io/projects/4q7jz8/) and finally, if successful, we package the code and assets. You can find a sample script to run the process for an app of your choosing here. To find out more about the thinking around the CI process, please see the ADR.
When the CI process finishes successfully and has published assets, we trigger the Delivery pipeline to the Dev environment.
Kodiaq (our merge bot) applies first-come-first-served policy to all PRs. To merge code to
main, developers add the
automergelabel to their PRs and Kodiaq will take care of the rest. Developers do not have privileges to merge/push manually to the main branch to prevent accidents from happening and maintain fairness, since merging manually to main would bypass the Kodiak merge queue.
Our deployment platform is Kubernetes and our applications' deployment and configuration is specified using Helm. Additionally, we have the configuration for our infrastructure in AWS specified using Terraform. These two configuration sources are hosted in two separate git repositories with restricted access.
Each application has a pipeline per deployment environment. The pipeline prepares (aka
bakes) the configuration for the concrete environment, waits for manual approval of the deployment and then performs the deployment with the freshly baked configuration.
- a Docker image tag - specifies which revision of the code/assets to be deployed.
- a Helm config tag - specifies which revision of the configuration to be deployed.
The CI process triggers the pipelines upon a successful build, which automatically deploys to our
Devenvironment. After manual approval, it is possible to deploy to