Using Git with multiple staged deployments

June 13th, 2008

Like most developers, at Curve21 generally have our applications set up with 2 remote environments - staging & production. New developments are deployed to the staging server for final checking & sign-off before being pushed out to the wilderness.

We've also (as many have) recently moved to using Git for a source control. A lot has been written about Git in the past few months and suffice to say we've found it fantastic. One thing I've not seen a lot about though is how to deal with different deployments targets.

Here's an idea we've had which we're trying out on a project. I'm interested to get feedback and to hear about any other ways people are working with Git.

The Idea

Basically, we need to be able to do the following:

  • Work on a new feature
  • Push the new feature out to staging
  • Switch back to the production code for bug fixing
  • Push the staging features to production

So, here's the setup we're testing out:

  • Remote repository has 3 branches - master, staging & production
  • Local repositories can push/pull to these branches

The 'new feature' workflow looks like this:

  1. Create a branch for a new feature
  2. Merge new feature into master
  3. Rebase master into staging
  4. Deploy to staging server
  5. When ready, merge staging into production
  6. Deploy to production server

With this setup, you have ultimate flexibility over what goes where. The master branch tracks the main development which is shared to all developers. When a new feature needs to be tested it can be easily pushed to the staging server.

If there are bugs to be fixed in production, these can be fixed in the production branch and deployed without picking up or affecting the items in development or out on staging. Capistrano can pick up any branch you ask it to for a specified environment.

Once we've tried this out and fine-tuned it, I'll post the results. If it works and others are interested, I'll sort out a tutorial for our we're doing it.

So - feedback & questions welcome!

Posted by stephen Filed in
del.icio.us | digg this

4 Responses to “Using Git with multiple staged deployments”

  1. Tys von Gaza Says:
    June 13th, 2008 at 06:37 PM

    Great idea. We just moved our system over to GIT and was wondering the best way to tackle dealing with a production and development environment. At this point in time we're just super careful and our master branch is production with side branches for testing, but there should be a cleaner way. I look forward to what you guys come up with.

  2. Ryan Mulligan Says:
    June 15th, 2008 at 03:36 PM

    I'm interested in the results of your experiment..

  3. pd Says:
    June 16th, 2008 at 07:38 AM

    Why would you want to deploy bugfixes directly from the production branch, without then backporting them to staging / master? Which, in that case, would be no different from pushing it to the staging server, checking your fix actually worked there, and then pushing to production.

    Have I misunderstood you or do you have a reason to do that?

  4. Stephen Bartholomew Says:
    June 16th, 2008 at 09:29 AM

    I guess that's really down to how you view the roles of the servers.

    For me, the staging server is generally used to try out new features before they go into production. Bug fixes are needed to fix existing features already in production.

    They would defiantly be merged back into the master branch and therefore onto staging.

Sorry, comments are closed for this article.