Continuous Deployment workflow

Development Philosophy

This article details the second part of our CI/CD workflow. Just as the Continuous Integration part, we try to reduce issue by having clear and documented workflows. One of the goals of Continuous Deployment is to reduce the complexity of deploying new features. By reducing the complexity we can release faster, more often and more reliable. This shortens the gap between idea and implementation, enhancing the user experience.

We use the concept of configuration-as-code. This concept outlines that the configuration of our applications should be defined in code. This code can then be version controlled and checked into GitHub. The repository dissco-core-deployment houses all deployment descriptions necessary to deploy a DiSSCo environment.

ArgoCD

To make sure our environments are a one-on-one representation of the configuration in the repository we use a tool called ArgoCD. This tool continuously checks the Kubernetes resources against the resources defined in the GitHub repository. It provides a dashboard on which we can monitor the state of our resources and the health of the applications. For a full Continuous Deployment we can configure ArgoCD to automatically synchronise with the repository on any change. However, in a production setting more control might be necessary. We can also disable automatic synchronisation and keep this a manual actions by one of the administrators.

Changing the configuration

Changing the configuration of a deployment is similar to change a piece of code.

1. Check-out the dissco-core-deployment repository
2. Make the required changes to the deployment files
3. Create a pull request with your changes
4. Get your colleagues to accept your pull request
5. Merge the changes to the main branch
6. If automatic synchronisation is enabled, you should now see your change on the cluster. If automatic synchronisation is disabled, you can now go to the ArgoCD portal and force a sync