Release process improvements
The current process has the following problems:
- CI in vs-deployment is too slow, we don't want to wait for that before being able to upgrade a chart
- Deploying an update of a service requires a vs-deployment update, which is partially manually
Quick process improvements:
- Push new charts before running the integration tests
- Automatically release vs-deployment on every service update (release pipeline for e.g. cache service pushes new cache chart version to vs-deployment master and also makes a release there with a postfix marking it as dev, e.g. build number of git hash)
- Run kubectl describe pod for each pod of the deployment (in the after-script) to find chart errors which prevent pods from starting
Architectural changes:
- Put all charts in 1 repo. Then chart releases can automatically create a vs-deployment release. However when releasing a new version of the service code (other repo), we wouldn't gain anything
- Use a monorepo. Service boundaries are still intact, but services are just different directories in 1 repo. Then bumping e.g. the cache service can automatically bump the cache chart and the vs-deployment chart.
A monorepo could also facilitate common code in the vs-common or vsq library (provided we accept some coupling).
Helm also has an appVersion field additionally to the version, which theoretically could be used to bump the appVersion independent of the version, but that can be confusing because you have the same chart with different contents.