Continuous Delivery
What is Continuous Delivery(CD)
The first paragraph from continuousdelivery.com
Why do CD
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.
Process overview
Continuous Integration(CI)
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 main branch without publishing assets. We trigger the CI process and publish the assets when making changes to main and release/** branches.
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.
Code and assets from island.is are packaged in Docker containers and stored in a private Docker registry hosted in AWS ECR. The ECR is configured to perform vulnerability scanning of all Docker images pushed to it.
When the CI process finishes successfully and has published assets, we trigger the Delivery pipeline to the Dev environment.
Merge queues
Github merge queues apply first-come-first-served policy to all PRs. To merge code to main, developers can use githubs "merge when ready" feature which sends PR's to the merge queue once all requirements have been met. 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 merge queue.
Configuration
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.
Delivery pipeline
The CI process triggers the pipelines upon a successful build, which automatically deploys to our Dev environment. After manual approval, it is possible to deploy to Staging and then Prod as well, via hotfix commit to the release branch.
We use ArgoCD as a deployment tool for Kubernetes. It minimizes manual labor required for deployments by automating which tags are synced (deployed) to our kubernetes clusters across all environments.
Developers are able to see the status of their deployments, logs from the pods including errors that are related to the applications, deployment templates (helm charts) or infrastructure in a simple web
ArgoCD organizes the deployments we use into Applications. There we can see information on all kubernetes objects that ArgoCD manages such as the health of the objects, sync status, helm values used, the URL used by the ingress for the app and a link to the configuration repositories.
Application level logs can also be viewed from there by clicking on the deployment and navigating to the logs tab
ArgoCD is a GitOps tool in which it continuously watches a configuration repository and syncs the status of the configuration to a number of kubernetes clusters.
In our setup, we build our docker images in the merge queue before PRs are merged to either the release branch or the main branch. Then after the merge another job pushes files to the configuration repo which triggers ArgoCD to sync the new changes to our clusters.
We automatically sync feature deployments, dev deployments and staging deployments without any user interactions. Production deployments still require manual sync actions at this point in time.
Last updated
Was this helpful?