5

We have a web app for which we have a couple of corporate customers. We have recently decided to offer it as a SaaS app and to follow the lean approach (in parallel with our corporate offering). Which means we've got experiments on the go that might not make it into production.

Before we went lean we were happy with the following branching strategy (I believe it's pretty standard):

  • master - always stable
  • dev - often unstable (feature branches cut off of dev for new features to go into the next major release)
  • major_release_x - live (cut off of master after dev has been merged into master, this is where bug fixes take place and merged back into master and dev)

Now we have the following in addition to the above and it's not working all that well:

  • lean_release_branch - live (cut off the major_release_x and contains experiments)
  • experiment_x - cut off major_release_x (this is where we hack the feature together and then merge it into lean_release_branch)

Our scenario now is that we need to release quick and often as the lean approach dictates, and when we get solid feedback on something arbitrary, then we need to productionize it and release it as soon as possible (off of the lean_release_branch).

The problem being we can't create a feature branch off of dev (as it is most likely unstable) and we can't create a feature branch off of lean_release_branch for two reasons:

  1. it has been contaminated by experiment code so this change/feature won't be able to make its way back to master
  2. the lean_release_branch always need to be ready to release, so we can't be busy doing testing and fixes on it (after merging the change/feature into it) if there's a critical issue that needs to be fixed and released

Does anyone know of a better strategy for our setup?

Niel de Wet
  • 7,806
  • 9
  • 63
  • 100
Markus Coetzee
  • 3,384
  • 1
  • 29
  • 26
  • in the second last paragraph, do you mean that after good feedback on an experiment that feature is redone must become part of the lean release? When does it become part of a major release? – Niel de Wet Jun 28 '13 at 08:24
  • @NieldeWet The "solid feedback" I am referring to would be on something unrelated to an experiment. Thus we would need to productionize straight away and release it as soon as possible off of the lean_release_branch, and subsequently it needs to find its way into dev to go into a future major release. – Markus Coetzee Jun 28 '13 at 08:52

3 Answers3

2

Besides GitFlow nozari mentions, there's also GitHub Flow. The place I work at used that as a basis (master is always stable, develop in feature branches, pull request with review before merging). We deploy less often then GitHub does, so on master we use annotated tags to track releases and lightweight tags point to whatever commit is in staging/production right now. This is managed by the capistrano-deploytags Ruby gem.

Unless I'm reading your problem incorrectly, you could achieve the same with this strategy with less complexity in all those branches.

Rafe
  • 753
  • 4
  • 20
0

I've just changed from TFS to GIT and the model I follow is based on this post.

Regarding you experiments it is just "featured branches" that will not make it back to develop (merged into develop).

nozari
  • 504
  • 4
  • 8
  • maybe a little different view on the nvie workflow: https://speakerdeck.com/ewoodh2o/a-sane-git-workflow – Zavael Oct 30 '13 at 14:04
0

Because everything in major_release_x is already in dev (since dev was merged into master before the last major release) an productionised feature (following a successful experiment) can be done on a feature branch off major_release_x, call it production_feature_y, and then merged into both dev, to be in the next major release, and lean_release_branch.

This way new production features are available in your lean release and will be in the next major release and the lean branch never needs to be merged back again.

Further customer feedback on the feature can be implemented on production_feature_y and merged into dev and lean_release_branch again.

Bug fixes can be handled in the same way, done on a branch off major_release_x and merged into both major_release_x and lean_release_branch.

Niel de Wet
  • 7,806
  • 9
  • 63
  • 100
  • This is actually how we have productionized a couple of pieces of feedback, but it's not working too well as it violates point no. 2: "the lean_release_branch always need to be ready to release, so we can't be busy doing testing and fixes on it (after merging the change/feature into it) if there's a critical issue that needs to be fixed and released" – Markus Coetzee Jun 28 '13 at 08:59
  • OK, but if you are doing a production feature on it's own branch, surely by the time it gets merged it should be production ready and ready to be released? – Niel de Wet Jun 28 '13 at 09:35
  • It first has to be released to a test server after it has been code reviewed and developer tested on its feature branch, thus it needs to go into a branch with a build job (but not the lean_release_branch as it needs to be 100% stable). – Markus Coetzee Jun 28 '13 at 09:41
  • @MarkusCoetzee, isn't that what your **dev** branch is for? – Niel de Wet Jun 28 '13 at 10:23
  • it's not a bad idea, but dev and the lean_release_branch could be quite different from each other. Ideally this branch needs to be as close to the lean_release_branch as possible so that we don't get any surprises when merging into the lean_release_branch. – Markus Coetzee Jun 28 '13 at 11:49