Are there Git workflows for rolling release web applications?

StackOverflow https://stackoverflow.com/questions/14551983

Question

My team of about a dozen developers produces a web application in a rolling release model: Once some featureset is ready, it's reviewed by a senior developer and pushed into the QA system, then into the production system. This usually happens several times per workday.

The VCS currently in use is SVN, and pushes to the QA and production system are done with a weird in-house deployment tool which works on the SVN, but file-based (so if you need to push a new version of file X, and X has unpushed changes from some other changeset that you don't want to push yet, you have a problem).

I plan to evangelize for switching to Git, so I'm thinking above how a workflow could look like. The usual suggestions like the often-linked Successful Git branching model don't apply since we don't have versioned releases.

Question 1: Are there any documented workflows I could look at for further inspiration, similar to the one linked above, which are optimized for rolling releases? Or would you suggest one?

I have tried to model a workflow on paper, which uses feature branches and master as usual, and has further branches which mirror the state of the QA and production servers. (One would only merge in there from master.)

The problem I'm not able to overcome is when something in master is not release-ready for some reason. For example, let's say the feature branch foo is considered done, merged into master and pushed into the qa branch. Then the same happens for the feature branch bar. Now on the QA system, we discover that foo is broken and needs more development, while bar is ready to be pushed into the production system. But there is no commit on master which includes bar, but not foo, so what shall we push? The only thing that comes to mind is to revert the merge commit for foo into master. (Behind the link, Linus explains several problems with reverting merge commits.)

Question 2: Any idea how to overcome this problem more elegantly?

Was it helpful?

Solution

Here is the workflow I have used with great success so far:

  • Each developer works on their features/fixes

  • Once they're satisfied with the work, they push the branch to remote

    git push -u origin newfeature

  • The QA or test [server | person | team] pulls master and the feature branch you want to release, and merges it into master but does not push to remote

  • Once the feature is QA'ed it gets merged with --no-ff and pushed to master

  • The feature branch can now be deleted

    git push origin :newfeature

  • The live server always pulls from master

For us this ensures that live server contains a rolling release of the current "best" code.

If you are interested in a branching model I have found this to be quite useful: nvie.com/posts/a-successful-git-branching-model/

OTHER TIPS

Don't forget that, with a DVCS, you don't have just a workflow of merge, but a workflow of publication (push/pull) between repos.

You don't have to impact master of your repo, when evaluating a feature.
You can push to a feature branch of a separate QA repo.

  • If tests passes, then QA/master is updated, and all developers can pull master from QA in order to update their master, while keeping developing other features (they would rebase their local feature branches on top of their updated master).
  • If test fails, QA/master is untouched.

There is documentation for workflows at the git homepage

Here's a nice slideshow worth thinking about by yourself. Nothing is perfect, try to fulfill your needs as much as possible.

Release Management Git Workflow

https://speakerdeck.com/ewoodh2o/release-management-git-workflow

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top