Releases as first-class entry
In 12-factor speak, a release is a build + configuration. e.g. a tarball of code and a set of environment variables. It's not common to put variables into existing pipeline artifacts, so it's easier to think of them as the "build" part, and project secure variables as the configuration.
GitLab CI/CD does not currently have any concept of a release in these terms. If you change a project variable, we don't re-deploy with those new variables. If you rollback to an earlier build, you keep the current variables.
Should have have a "release" as a first-class entity in GitLab CI/CD?
Some possible implications:
- We could store records of releases, and increment the release version every time the build or config changes
- We could re-deploy any time a variable changes (and thus a new release is created)
- Rolling back could apply to releases rather than builds, thus rolling back would roll back variables as well
- We'd have to manage the relationship between project variables and deploy variables better - For example auto deploy should pass variables to helm charts, k8s objects, and docker images in some consistent way.
- We may need to differentiate the target of variables. e.g. is the project variable just used during CI/CD, or is it to be bundled into the release (and thus deployed)? This is the difference between compile-time and run-time variables. In our case, it gets more complicated as there could be helm, k8s, and docker variables too. Do we need to have multiple scopes? Let's hope not. One answer is to ignore the complexity and just make all variables available everywhere, much like Unix environment variables, and just let each piece parse whatever they need and ignore the rest.
Links / references
(Write the start of the documentation of this feature here, include:
- Why should someone use it; what's the underlying problem.
- What is the solution.
- How does someone use this
During implementation, this can then be copied and used as a starter for the documentation.)
It is also needed to store the value of a deployed revision somewhere for those who use kubernetes helm. Once a helm chart has been installed or upgraded, it obtains a integer revision id, which cannot be customised (e.g. you cannot set it to
CI_COMMIT_SHA). The rollback script looks like this:
helm rollback my-release $REVISION.
It seems that currently there is no good way to store the value of
$REVISIONfor each deployment, which is only known at the time of
helm upgrade. A workaround can involve an GitLab artifact, which is a text file with revision id, but that's too bulky in my view.