We run a deployment pipeline where we build a versioned binary, tag the commit it was built from with the same version as the binary, and then can deploy the binary into arbitrary environments (typically qa, then live).
I'd like to keep a record of which commit is currently deployed in an environment as a git tag or branch on the canonical remote repository.
I'm imagining a branch or a tag called
prod or whatever) and a deployment process that on successful deployment moves that tag / hard resets that branch to the commit that is deployed, so in principle you can just do a
git pull && git checkout live and (race conditions aside) you're looking at the code that is currently deployed in live.
However, neither tags nor branches quite measure up...
Branches might feel more correct in that they are pointers that are meant to move between commits. However, in a world where people can roll back, a branch with its assumption of always moving forward doesn't quite fit. Resetting the remote
live branch to an earlier commit will mean that a dev checking out
live may be ahead of the remote branch and will need to
git reset --hard origin/live to get back to what is actually in live. I can also imagine a situation where pulling might present you with a nasty merge conflict. We'd also need to protect the branch as it would not be intended for developers to commit and push to it.
On the other hand tags aren't really designed to move; if you move a tag on the remote repo, a
git pull --tags will fail as so:
! [rejected] live -> live (would clobber existing tag)
unless you do a
git pull -f --tags.
Still feels like tags are slightly the better option, as they convey the idea that it's just a marker, not a work in progress.
Does anyone have a view either way? Or is there a Third Way of some kind? Or is trying to do this just a bad idea? We bake the git hash into the binary and allow easy reading of it, so it's not a huge hardship to go to the environment and find out which commit is deployed there. It would just be convenient to be able to see it in the git log.