Code Promotion with Git

Question

I'm trying to figure how can I use git for multiple environments (dev->test->prod) with code promotion. I read a bit about branching but didn't understand much how can this solve my problem since I must have the ability to run all of the environments concurrently and separately from each other.

Will be very thankful for some kind of how-to.

Copp

Do your environments have different code? If they are all the same, I see no reason to branch, just clone. – Platas

Answer 1

It seems to be quite the common theme to have this three-tier workflow. Here's how we've done it. We're a Ruby shop, so there's some mention of testing here too.

We all work on individual "stories" (from Pivotal Tracker) separately from each other. This means that if we were all committing to the master branch, then we'd be stepping on each other's toes constantly. To stop this problem, each of us creates a new branch (based off the latest master) for that specific chunk of work.

When we complete that chunk of work, we run the tests ourselves and if they're passing then they get merged back to the master branch where the tests are ran again to ensure that there's no breakages that have been introduced. If there have been, we try using git bisect to figure out what it was, and that works in 99% of cases.

Most of the time (because we're really awesome*), the tests pass. When all the tests are passing on the master branch then we deploy to our staging server. So I guess this means that master is the staging branch. When that feature (or more likely, features) have been given approval, then we merge those changes into a production branch and then push that branch up to the production site.

With this setup, the individual developers are all able to have a runnable copy of the application for themselves, the QA team gets a running copy to go over when they have the time (this is the "most fun" part of my job, gathering people is like herding cats) and the Real World has a perfect site.

In theory, anyway. People make mistakes.

Polyethylene

Answer 2

DVCS introduces another dimension to versioning:
"Publication" (push/pull)

Code promotion used to be made exclusively through branches, or through labels.

For environment with multiple contributions, local individual branches like Ryan describes works best.

But with DVCS, you can simply push a code base to a dedicated repository and consider that clone as the "test" promotion environment.
Usually, you would first rebase your current work on top of the remote promoted code to resolve locally any conflict. And then you would push (fast forward merge on the remote side).

So it is another tool you can use for code promotion (while still using branches or label: typically, "production" is best identified by a branch).

Sycee

Answer 3

Im my case, git push is for publishing files from dev to testing server. Then we do daily (or weekly) builds (using phing) to export the app to the production server (there is no git repo there) or publish the tarball with the source code to download.

The workflow depends on your project specific variables.

Switching the servers is not only differentiating the code versions, but the databases, environments, configs, users too.

Natural way for changing all the options at once is changing the repo too, so pushing between the dev/test/production repos.

But you may write your own git hooks responsible for all these switches. There are many hook options you may choose from. Branch is just a commit, so you can have post-commit hook, exporting just specific tags, or exporting the content of particular branch.

Canzonet