Continuous Delivery
Last updated
Was this helpful?
Last updated
Was this helpful?
The first paragraph from
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 main branch without publishing assets. We trigger the CI process and publish the assets when making changes to main and release/** branches.
When the CI process finishes successfully and has published assets, we trigger the Delivery pipeline to the Dev environment.
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 Dev environment. After manual approval, it is possible to deploy to Staging and then Prod as well.
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 . To find out more about the thinking around the CI process, please see the .
Code and assets from are packaged in Docker containers and stored in a private Docker registry hosted in AWS . The is configured to perform of all Docker images pushed to it.
(our merge bot) applies first-come-first-served policy to all PRs. To merge code to main, developers add the automerge label 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 . Additionally, we have the configuration for our infrastructure in AWS specified using . These two configuration sources are hosted in two separate git repositories with restricted access.
We use as a deployment tool for Kubernetes. We have a few application pipelines that are identical for the most part.
The pipelines are defined and versioned in . The input to the pipelines is as follows:
The chart stored in our comes in as an asset as well as value files containing environmental specific values. Docker tag, value files and helm chart are baked together creating Kubernetes manifest, that can be deployed to a specific environment.
Our Spinnaker is accessible . Note that to be able to log in, your membership to the island-is github organization must be set to public. You can change that .
