59

We recently had a problem whereby a feature for our webapp (automatic signup) was postponed by management because they felt the start was too "cold" but they wanted all the other features we had been working on to go live.

The problem is that this functionality had been merged into develop when it was finished along with all the other features that we expected to push live on the next release so we couldnt just merge dev -> test -> master like we usually do.

How could we have avoided this issue?

Calin Leafshade
  • 1,991

4 Answers4

77

One approach is feature flagging it. It can live in the code base but be disabled by configuration.

Another option it to make a revert commit that reverts the feature merge so that it's not in develop any more. A new branch can be made which reverts the revert, and be left pending to merge later. If you're using Github pull requests, you can do this easily with the "revert merge" button on a merged pull request.

Daenyth
  • 8,147
27

How could we have avoided this issue?

From a process perspective, figure out:

  • Who was the decision maker to start this work?
  • Why did the decision to release this feature change?
    • Missed expectations?
    • Miscommunication?
    • Inadequate business support?
    • No customer involvement?

More than likely there were drops in communication along the way. This is important to have because when it doesn't work, your development process(es) will be based on false and wrong understandings of business requirements.

enderland
  • 12,201
  • 4
  • 53
  • 64
20

Forget for a moment the issue with your management, and imagine you had the "automatic signup feature" already in your latest production release, deeply integrated into your codebase. Now you get the new requirement to add an "off-switch" for "automatic signup". How would you handle this in your Git workflow?

I guess you would declare "disabling of automatic signup by configuration" simply as an additional feature (it is just a form of Feature Toggle), so this should integrate smoothly into your workflow. You can estimate the effort, if you like you can use a feature branch for it (or not, if you do not use feature branches for such issues). And you can definitely use the usal "merge dev -> test -> master" flow you described.

And that is actually the way you can handle this in your current situation. From the viewpoint of the git workflow, it should not matter if the change request comes from management for release 1.0, or if the change request is a new customer wish for release 2.0.

Doc Brown
  • 218,378
2

This is the exact issue I have with gitflow and GitHub flow, and it seems that with web applications this happens often - or more like the norm. It seems you would either resolve this issue retroactively (mentioned above) or proactively (example below).

I've created 'bundle branches' in addition to the standard gitflow branches. The bundle consists of all the features that are ready for uat/qa. A list of uat/qa features are created. These are merged into the temporary bundle, and that bundle gets deployed to uat/qa. Any bug fixing happens on the original feature branch, and that gets remerged back into the bundle and deployed. This separates the coming release as well as allows testing those features together prior to them finding their way to the develop branch. Those branches that are approved get a pull request into develop - following the gitflow process. Test ready features can be added to or removed from the temporary bundle branch and redeployed.

  • This keeps master always reflecting production-ready state (can automate with hook)
  • Develop always reflects latest delivered (and tested) next release candidate

Cons include managing the bundle list and adding another branch type; however, besides the retro fix, which I think is too late, this seems to be the more viable solution.

With a GUI addon, it might be optimal to tick off feature branches per bundle deployment - with automation in mind.

David Latty
  • 71