One Git ref instead of thousands: a better way to track release history
Maybe a better way to track the release history of a Git repo
A former ZipRecruiter engineer describes how deployment tags bloated their Git monorepo, slowing down daily operations. His 2019 proposal replaces thousands of refs with a single ref per app and tier, using a linked list of metainfo commits. Each metainfo commit has two parents: the actual release commit and the previous metainfo commit. This makes release history queryable with standard Git commands like git log, enabling easy rollbacks and diffs.
Git is well-designed for handling thousands of commits, but not for handling thousands of refs.
- duesabati
Release should be separated from deployment, there should be virtually no difference between the code running production and other envs, instead of creating a release per environment you should just tag your code with an easy to read label (e.g. a version number) produce artifacts from that version of the code, then at deploy time you decide (either manually or through an automated logic) which version of the code you want to use. Ideally all "differences" at runtime between production and other envs should be defined at, well, runtime i.e. through environment variables (even the frontend stuff that you see usually made at build time, there should be a mechanism at runtime to avoid it) this way you have much more predictable behavior and it's easier to reason on, also you can physically separate building from deployment pipelines, so you can have much more agility on switching to whatever is needed, it's also much more easier on the brain (and for LLMs) to clearly see the steps and fix ci pipelines problems.
If you really need build time differences, then you should identify this difference by what really is not by the env you assume it will run on, because explicit is always better than implicit, especially for LLMs and new devs.
- turboponyy
> It seemed reasonable to me record the deployment history in the repository
That doesn't seem reasonable to me. You'd be using Git for persistence concerns that are not directly related to source code management.
"Environment X had commit a1b2c3d deployed at 1970-01-01T00:00:00Z" is all you need to store, and I don't see why you'd want to do that in the repo itself. Commit a1b2c3d exists regardless of where or when it's deployed.
Store that data in the thing that handles the deployments.
- wrxd
> our Git monorepo was developing an annoying problem
Sentences like this are so common from people using monorepos that I am convinced they actually introduce more problems than they solve