Improve the AutoDevOps Helm chart and CI file
Problem to solve
Currently, the AutoDevOps Helm chart is quite rigid. It expects projects to follow a specific pattern and if the project has some deviations from this pattern, which happens quite often, the AutoDevOps chart becomes unusable. Then, developers are forced to create their own charts and get into a maintenance hell with these charts.
Developers that need to do a bit more, or a bit different, than the AutoDevOps chart assumes.
The AutoDevOps chart should be adaptive for use-cases that aren't exactly following the expectations for GitLab default AutoDevOps pipeline. For example, the AutoDevOps feature is effectively useless for .NET Core developers. But, when we change it slightly, everything works fine. However, maintaining the custom chart becomes a hassle, since GitLab keeps adding things to the default pipeline and the chart and we need to watch those changes closely to replicate them, to stay relevant with the latest updates.
Current issues include:
- Required dependency to Postgres in the Helm chart
- Lots of references to Postgres in the CI file
- No way to add other dependencies (like Redis, MySQL, etc) to the chart without creating a custom chart
- No way to give other environment variables to pods, except the
DATABASE_URL, which is tightly coupled to Postgres
- No way to customise timeouts for readyness and liveness probes
- No way to customise resource limits for pods (limits are commented out in the
I am not quite sure what the best solution for all of those issues is. The last two can be easily fixed by uncommenting limits from the values file and adding more defaults to the values file. Postgres dependency, though, is much harder to solve. Environment variables shouldn't be a big issue to solve.
Helm suggests how to deal with composition, by keeping the umbrella chart and charts for dependencies separated: https://helm.sh/docs/developing_charts/#complex-charts-with-many-dependencies
What is the type of buyer?
- Enterprise customers that use .NET Core (for example)
- Enterprise customers that use anything else than Postgresql for persistence