2

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?
Improve this question

1 Answer 1

Reset to default
3

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
Improve this answer
3
  • That all being said, there are still quite a few examples of people using git in the way that I describe for deployment. By no means a long term strategy for me, but something just to hold us over until we can dedicate the time to getting up and running with continuous integration.
    – Alexander Trauzzi
    Dec 1, 2014 at 13:11
  • The problem with that is that as a short term strategy it tends to end up building massive amounts of technical debt, which gets harder and harder to pay off the longer you wait.
    – l0b0
    Dec 1, 2014 at 18:55
  • Totally agree and my question is part of a larger plan to get CI in place.
    – Alexander Trauzzi
    Dec 1, 2014 at 21:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.