5

We've been following git flow loosely at work now for the past few months, but have been running into issues with lengthy QA waits.

Here's our process:

  • developers develop locally on feature branches
  • when the team thinks the feature is ready, it's merged into dev, pushed to dev server (Codeship & rsync)
  • client approves feature
  • feature merged into master, pushed to prod

Unfortunately, the client can sometimes take up to weeks to approve a feature. It could be due to backlogs, content creation, staff turnover, etc.

However, in the meantime, a new feature may have been merged into dev and be pushed to the dev server for approval. Say this 2nd feature gets approved and needs to be deployed ASAP (of course). How am I going to get that 2nd feature off of dev without bringing the 1st feature?

ru3sch
  • 786
  • 7
  • 20

3 Answers3

4

How am I going to get that 2nd feature off of dev without bringing the 1st feature?

You won't.
But once dev is merged in master, you can revert the 1st feature commits from master, in order to record that 1st feature wasn't approved yet.

This is safer than cherry-picking the commits from the second feature, as it would duplicate those commits from dev to master, and render a future merge more complex.

If this is repeated often, then the workflow isn't adapted to the current development process.

If would be best if:

  • you have an integration branch in which you merge any feature to be approved (on the dev server).
  • dev were to be updated only with approved features from the feature branch (on the dev server).

In other words, you merge a feature branch twice:

  • once in integration for a formal client review and approval of the feature
  • once in dev, with a second (and quicker) client check, to see if the feature still works as expected (since it isn't merge in the same codebase as the one in integration)

From dev, you resume your normal release management process (pushing to prod)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • By reverting a commit on `master`, do you not run the risk of destabilizing that branch, though? – jub0bs Sep 03 '14 at 06:57
  • @Jubobs how would that destabilization materializes? (note: I agree that it is a workaround, `master` shouldn't be tampered with) – VonC Sep 03 '14 at 06:57
  • Can a `revert` operation not give rise to conflicts? – jub0bs Sep 03 '14 at 07:02
  • @Jubobs conflict when reverting? (http://stackoverflow.com/a/6084535/6309) or when merging again `feature1`? (although you have http://stackoverflow.com/a/8730046/6309) – VonC Sep 03 '14 at 07:05
  • @Jubobs I wouldn't call that "destabilization" though, but if that issue arises too often, then the second part of my answer should be taken into consideration. – VonC Sep 03 '14 at 07:07
  • we ended up going with something very similar to the integration branch idea – ru3sch Oct 18 '14 at 07:13
1

We have this same issue in our environment, with the client taking a long time to test some features (weeks!) and approving others in the mean time that are supposed to be deployed in production.

The way we are dealing with this is using Gitflow normally and adding Feature Toggles to our features. This way, we can push the new feature code to production, but inactive due to the feature toggle. We can configure if a feature is active or not using a properties file (we are using Togglz).

Sure, the code gets a bit messier with all the "if"s, but the advantage is that if a feature that is already in production, but disabled, gets approved, we just need to change a property in a file and restart the application and it becomes active, no need to do a new release and install it in production! Also, Togglz has a feature console (which we haven't tried yet) that apparently can do the toggle in runtime.

You can learn more about Feature Toggles here. You can learn more about Togglz here and here.

I hope this helps :)

vribeiro
  • 46
  • 2
0

This is not "git-flowy" enough. Development branch should contain only features that got their sign-off - So the HEAD in development should contain only code that was tested and is ready to be released to master/production.
The git-flow solution to your problem is that on finishing work on feature you upload it to origin (push the feature) and send it to the tester (client?). Only when approved it will be merged to Develop.

Feature should be independent to one another, so the client could test each one separately on his schedule(*). On your flow you might have good code and bad code merged together and the test result will not help to identify the source of the problem.

*) just if this isn't the case, or in case that you want to test feature in parallel use the integration branch.

isaac-fisher
  • 95
  • 1
  • 8