Our company has a few dozens of different project repos. I just created a repo for storing deploy manifests (versions, etc. for every repos of a product), and then let our automation pipeline commit the manifest. Simple to follow and no source-unrelated crap in source repos.
One step further: use `git tag` for what it's for: tagging a given commit with an immutable reference (say, a version number like `v1.0.23`), and generate and publish "build artifacts" (`my-application-v1.0.23.tar.gz`, `my-application-v1.0.23` binary, `my-application-v1.0.23.tar.gz` helm chart, `my-application-v1.0.23` container image, `my-application-v1.0.23` ... whatever binary artifact)
A quirk here- tags are not actually immutable in git. I agree with the premise, and use tags myself for releases, but if you rely on them being immutable then you have loaded a footgun
Agreed. I get that you want to know the last few releases and maybe even all the releases to production. But all the releases to staging as well!? What possible use-case do you want to solve which version you released two years ago to staging?
I've stopped reading the article actually before the actual solution.
You can kind of arrive at the same solution, without actually thinking about all this, by just merging into a release branch when making a release.
Complicated and unintuitive.
Our company has a few dozens of different project repos. I just created a repo for storing deploy manifests (versions, etc. for every repos of a product), and then let our automation pipeline commit the manifest. Simple to follow and no source-unrelated crap in source repos.
Or commit a file to main that represents a release and build your automations off that
One step further: use `git tag` for what it's for: tagging a given commit with an immutable reference (say, a version number like `v1.0.23`), and generate and publish "build artifacts" (`my-application-v1.0.23.tar.gz`, `my-application-v1.0.23` binary, `my-application-v1.0.23.tar.gz` helm chart, `my-application-v1.0.23` container image, `my-application-v1.0.23` ... whatever binary artifact)
A quirk here- tags are not actually immutable in git. I agree with the premise, and use tags myself for releases, but if you rely on them being immutable then you have loaded a footgun
true — they only are immutable by convention and because the git command refuses by default to modify/push an existing tag.
Cool and clever.
One question: what do you use your old refs for?
We just delete them when we get too many.
Agreed. I get that you want to know the last few releases and maybe even all the releases to production. But all the releases to staging as well!? What possible use-case do you want to solve which version you released two years ago to staging?
I've stopped reading the article actually before the actual solution.