I’ve been researching git deployment flows and have seen many post-receive hooks that will check out master. Few of them however detail how you might set up a beta server that could be running any arbitrary commit ref.
My first thought was that you could set up a branch per environment and then push it. But I’m wondering if that has any inherent limitations, especially if someone wants to test a beta with “slightly behind” code.
After that, I figured a tag might be nice because then you can tag any reference anywhere in the repository and whatever it’s set to is what gets checked out by the beta.
The only drawbacks there would be that I could see the repository getting polluted with deployment information.
So, specific questions are:
- Is there a body of information in my repository with better semantics that I can use in lieu of just hard-coding beta/staging/live environment information in tags/branches?
- Should I be using branches or tags to do any of this?
- Will I need one bare repository per environment so that each one can have a different post-commit hook?
Some facts:
- Git is a source control management system, not a deployment tool or configuration management tool
- There are many stable deployment tools out there: TAR, RPM, Fabric, etc.
- Ditto for configuration management tools: Puppet, Chef
- Released history is immutable (the alternative is just crazy)
- A product is in beta for several commits
Conclusions:
- Branches/tags used for ephemeral configuration either have to be deleted (making history mutable) or use a custom naming scheme (cluttering up the history) to avoid collisions when for example a new revision becomes the active beta
- With so much custom semantics you will require a lot of custom code to release this
3