Deploying and testing features on a server by more than one developer

Question

I have 4 environments (prod/preprod/SIT/DEV), also two main branches (Master & Develop), two developers work on features (One & Two).

Developer One creates a feature (Feature A), he then merges the feature into the Develop branch.

Developer Two also creates a feature (Feature B) and he does the same, he merges the created feature into the Develop.

Now, the Develop branch will have two features (A & B), when the business owner decides to go with one feature ONLY (feature A), what should be the right approach to follow?

what is the best GIT workflow that we should follow? especially when implementing DevOps solutions.

P.S. I only mentioned two developers with two features, while in real life, I might have many more at the same time, hence I need to know the best approach to follow.

Answer 1

Since you have a single released version product one thing to consider would be keeping the Develop branch or not:

• keeping it would have the advantage that at any moment you can bring in a hotfix in master even if Develop isn't stable enough for a merge into master. But this means you'd need to have 2 focus points instead of a single one - both branches need to be kept stable. There will be additional efforts for constant merges back and forth between the 2 branches to keep them from diverging. The overhead of context switching between them can be significant.

• getting rid of it (see How to get rid of develop branch for simplified Git flow) and doing the integration directly in master would reduce the overhead of carrying together 2 branches. The releases would simply be tagged versions of the master branch. But getting in a hotfix for the current release version would require the branch to be stable enough (virtually ready for a new release) at any moment. Which would be desired anyways and is achievable (with some effort).

In the context of continuing the practice of developing features in isolation (on separate, potentially long-lived feature branches) and going through the pains of integration hell one thing that could be improved would be a better communication between the business owner and the development team: deciding to drop feature B after it was integrated into the product is practically equivalent with adding a new feature C (late in the game).

Another (much better IMHO) option would be to switch to the Continuous Integration practice: features would be developed directly in master (using very short lived branches carrying tiny incremental changes much easier to handle, ideally merged back into master in less than 1 day), behind feature toggles/feature flags:

• during development the features would be disabled by default, making master virtually equivalent to the current release version, ready to receive hot fixes if/when needed.

• the flags can be individually enabled in various environments to determine the respective feature progress/readiness for release. This can be done simultaneously for virtually any number of features (or feature combinations), regardless of their size or development stage or duration, as different verification steps of the automated CI system.

• whenever a feature is ready and the business owners decide to accept it the respective flag is turned on in a tiny commit and a new tag "brings" the feature into the next release. No massive branch merges, no risk of surprises, everything should be just business as usual - all kinks should have been already ironed out. A much more predictable (and less stressful) development process.

• keeping the flag supporting code in place for a while also allows staging the dropping of the feature in a subsequent release by disabling the flag in a CI system verification stage. But eventually a cleanup of the feature flag and the supporting code can/should be done as a background code base maintenance task, making the feature permanent.

IMHO such approach is the only reasonable option in larger scale projects where many features are being developed simultaneously.