Has anybody implemented a Jenkins-X style workflow in Gitlab CI? I’m about to do so, and I’m hoping I don’t have to reinvent the wheel. That workflow is something that Jenkins-X does much better than Gitlab auto-devops IMO.
Here’s a quick description of the Jenkins-X deployment flow:
When you import a repo R into Jenkins-X, it gets added to one or more “environments”. An environment is a repo that knows how to deploy all of your services. This environment repo contains a Kubernetes helm chart. This helm chart is empty except for a requirements.yaml file to declare dependencies on the repos you’ve imported. By default Jenkins-X associates the master branch of all dependencies with a staging environment.
So then when you push to master on repo R, Jenkins-X:
- runs unit tests
- requests a new version number for R on github
- builds a helm chart and uploads it to a local chartmuseum
- creates a PR on the staging environment that updates the requirements.yaml manifest on staging with the new version of R
- merges said PR
- waits for CI/CD of step #5 to complete
You’ll notice that it’s not the CD of repo R that actually deploys that repo, it’s the CD of the environment. Of course helm is smart enough not to always deploy all of it’s requirements, it only deploys the requirements whose version has changed.
I laid out the flow for staging, but you can probably imagine how useful this is for Review Environments – the Gitlab auto-devops review environments only bring up a single environment, which is often not very useful in isolation.
We might not use helm; not a big fun, plus Gitlab doesn’t bundle chartmuseum like Jenkins-X does. It’s the flow I’m interested in, steps 4, 5 & 6. And we might be able to skip step 2 by using gitsha rather than version numbers. At first glance it seems like it should be relatively straightforward to impliment in a .gitlab-ci.yaml using the API, but it’d be nice to not to have to start from scratch.