CD upgrades
We are currently managing deployments for VS and in some cases we are more responsible than others (agri more than prism mayhaps).
The number of deployments may keep growing and manually dealing with flux can become a bit of a nuisance. Its may be worthwhile to review the following two features in the existing toolchain:
- gitlabs environments: https://docs.gitlab.com/ee/ci/environments/
- flux webhook receivers: https://fluxcd.io/flux/guides/webhook-receivers/
One solution for deployments that need to be kept updated is to create deployment scripts that check out a repo on each tag (which we already do/did to an extent) and maybe a webhook to trigger reconciliation. It may pair with the gitlab feature of environment management, and perhaps down the line even monitoring/observability (check the monitor tab on left, much empty!
Consider the following:
stages:
- test
- chart
- staging
- deploy
...
staging:
stage: staging
environment: staging
only:
- main
deploy-ama:
stage: deploy
environment: ama
only:
- tags
deploy-dafm:
stage: deploy
environment: dafm
only:
- tags
However, at how many environments / sections in .gitlab-ci.yml
do we say that it may be too much?
There is some new bleeding edge development as evidenced with this documentation
- https://docs.gitlab.com/ee/user/clusters/agent/gitops.html - here its mentioned to use flux
- https://docs.gitlab.com/ee/user/clusters/agent/gitops/flux.html - gitops flux agent in beta
- https://about.gitlab.com/blog/2023/02/08/why-did-we-choose-to-integrate-fluxcd-with-gitlab/ - blog post couple months fresh
- https://gitlab.com/tigerwnz/minimal-gitops-app/-/blob/main/ - sample repo
Could maybe deprecate or further augment https://vs.pages.eox.at/version-tracker/