

Ask HN: What's your dev teams git multi-environment setup workflow like? - jqueryin

I've been scouring the web for different git workflows to find one that would work for my development team.  I'm looking to add development, staging, and production remotes.<p>I'd like to hear about your workflows entailing multiple environments, as I haven't locked down on any one particular solution.  If you have any links, those would be appreciated as well. Thanks!
======
slashbunny
We are using 3 remotes with Git on a team with 5 people. Here's how we do it:

* "dev" branch: This branch holds all development code and code being tested on our development site

* "master" branch: After code has been fully developed and tested, it's moved into the master branch. This code sits on our staging site.

* tags: We tag commits on the master branch, which represents a production release. We tag releases using the format YYYYMMDD.##, so if there was a release today, it'd be 20100929.01. If there was another, the ending number would increment.

All development is branched off of master to start in a feature branch. Once
it's ready for testing, it's merged to dev. When it's considered ready for
release, the topic branch is merged into master. After final testing, master
is tagged and the feature is released into production. We use a shared central
repository on the network, rather than trying to manage branches between one
another.

One consideration you might want to think about is "dead" code in your
development branch. We have had instances where, for whatever reason, code was
developed in a topic branch, merged into "dev", then development stopped. It
could have been changing priorities, changing requirements, "oh never mind, we
don't want that", or whatever. To combat the issue of "dev" having a bunch of
junk (which confounds testing), we "refresh" it monthly. An automated process
on our continuous integration server simply deletes the "dev" branch and re-
creates it off of "master". Then, an email is sent to developers telling them
to do the same thing and to merge their topic branches back into "dev". Of
course, this means that "master" and the topic branches must have all our
code, no development must be done in "dev" directly.

To automate all this, our continuous integration system (Hudson) monitors the
"dev" and "master" branches. If there is a change, it runs some basic checks
(lint, unit testing, etc), then rsync's the code to the appropriate web server
automatically. For production releases, it's (intentionally) a more manual
process. Tagging must be done manually and a programmer must go into the CI
server to kick off the production release by specifying the tag to release. If
we need to roll back to the previous release, the process is the same.

I think having a central repository and a system automate deployment to the
remotes is essential and probably more important than your particular git
branching scheme. It's made our lives much easier and has caught countless
problems (and spammed us via XMPP) that we might not have noticed if
programmers were just "git push"ing to the web servers.

------
bnoordhuis
In a nutshell:

    
    
      1. All developers push to the remote master
      2. Acceptance testing is done against the master
      3. Once accepted, the release is tagged
      4. The release is exported to production
         with `git archive` or `git checkout-index -a`
    

For larger teams you might need fine-grained control, but it works great for
our small team.

~~~
jqueryin
Thanks for the input. I've been noticing a pattern of "don't use version
control in production" which makes complete sense with the export. Do you guys
have any kind of staging environment where things get final approval from a
third party? I'm in a situation where we have a client approval process which
requires another intermediary to production. It basically sits on the same
production box but is used for testing prior to going live.

If it helps with anybodies responses, my situation is particular to web
development.

~~~
madhouse
staging would fit well within the work flow outlined above: you just branch
out a staging branch, and export that. If the client needs any fixes, you fix
it on the stating branch, and merge it back to master.

That way, further development on master won't disturb staging.

Once the client is happy, tag staging and export it to production.

------
ryanwaggoner
We use this:

<http://nvie.com/posts/a-successful-git-branching-model/>

~~~
jqueryin
How would one take this git flow model and add a third environment, staging,
to sit between master and develop?

My initial thought would be to not change anything in the structure and to
simply run a deployment script to export to the staging site using
scp/ssh/rsync and ensure things are working properly before doing the same
thing on production.

~~~
kyleslattery
Just think of the release branches as staging branches--once something's ready
to move from develop to staging, you make a new branch, so you can keep
working on develop while you test staging.

------
jjanyan
Concurrent development with maximum flexibility:

It might be a bit hard to follow, but this is the branching strategy we
follow.
[http://tinypic.com/view.php?pic=15wi351&s=7](http://tinypic.com/view.php?pic=15wi351&s=7)

We use jira for managing our code changes and requests. Each ticket has its
own branch. Everyday we merge the tickets we want to go out into a release
branch, as you can see in the image. Release, then merge into master once we
are satisfied with the release.

The benefits of this strategy is having maximum flexibility in releasing any
code change. A request can be made, completed, and released in the same day,
often in combination with changes that have been in progress for weeks.

The draw back is managing which branches are going out when, more so with
teams greater than 20. It takes knowledgeable team leads and release managers.

------
agotterer
This isn't exactly what you are looking for. But this is what we use to handle
our tagging and deployment to staging/production.
<http://github.com/apinstein/git-deployment>. It's a capistrano multi
environment recipe that automates a lot of the tasks.

------
Mamady
I understand that git is the new hip version control, but if everyone uses it
with a 'master' branch... why bother? Why not just use subversion? It defeats
the whole purpose of using a distributed version control system.

~~~
bnoordhuis
Fair question. Two reasons (at least):

1\. Git is much, much faster than Subversion. A real-life example: merging two
branches with about 2,000 commits worth of changes (~250K lines added, changed
or deleted) took over _6 hours_ with svn but <15 minutes with git. It's not
just network overhead, our network is plenty fast.

2\. Though you push to a remote master, that doesn't mean you can't branch
locally. You can and you should; it makes it easy to work on multiple features
simultaneously.

Then there are things like `git stash` and `git archive` that make life just
that much better.

------
zackola
This is how we do it. [http://reinh.com/blog/2009/03/02/a-git-workflow-for-
agile-te...](http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-
teams.html)

