4

We are struggling with our Git Flow process, and deploying features to our Test and Live environment:

  • We want all features that is ready for testing, be combined and deployed to the Test environment.
  • We want to deploy only specific features to the Live environment

The problem with the way we use Git Flow:

  1. Developer A follows the normal gitflow process to create a feature from "develop", and does his development in a new feature. When ready for testing, he merges his feature into the "develop" branch, and deploy the "develop" branch to the Test environment.

  2. Developer B then follows the same process. Both features are now merged into the 'develop' branch, and both changes visible on the Test environment.

  3. The Client does the testing on the Test environment, but only approves changes made by Developer A to be released to the Live environment. So he will create a new 'release' branch from 'develop'. But this issue is, this will include change from Developer B.

What is the best practice to only release changes from Developer A?

Currently we are following the procedure below, which allows us to release to the Live server per feature(s). But there must be a better way?

We follow the normal Gitflow setup, but we also create a new branch called "qa", this will be created from the master "branch". This is the procedure we follow:

  1. Pull latest "develop" branch
  2. Create feature from "develop" using gitflow
  3. Do all development in a feature
  4. Once ready for testing,
    • pull latest "qa" branch
    • while in the "qa" branch
    • merge your feature into "qa"
  5. Release the "qa" branch to the QA server
  6. If any bug fixes need to be done, repeat from step 3
  7. If the client for some reason do not need this feature anymore, and it needs to be removed
    • Delete the feature
    • Undo your merge to qa
  8. If client happy with testing, select your feature, and follow the git flow process to finish the feature. (This will merge into "develop")
  9. Select Development branch, and create new release using GitFlow
  10. Finish the Release using Gitflow (or bundle multiple releases if needed)
  11. When ready to go live
    • make sure you are in the master branch
    • if possible, test the project and changes
    • copy all files needed to the Live server

But by creating this "QA" branch, we are not using the development branch at all as its intended, making it redundant.

I read through these answers, but doesnt quite help us, or I don't understand here and here

Community
  • 1
  • 1
David Smit
  • 709
  • 1
  • 11
  • 30
  • 1
    To me a feature in only finished and merged into `develop` once it is fully complete. If approval is still pending, then that’s a step required for it to be complete. If features need to be approved/revoked by the client individually why don’t you release and test them individually in the QA server straight from the each `feature` branch? In your example, before finishing the feature but once it’s ready for testing, Dev A would push the feature A branch directly to the server and Dev B would do the same for feature B. – Hugo Ferreira Jul 10 '15 at 18:50
  • 1
    This would probably mean that the QA server’s repo would now contain those feature branches. On the server you’d setup several virtual hosts endpoints where each feature branch would be checked out for evaluation by the Client (e.g. client check feature A in one url; goes to see feature B in another url, etc.). The ones approved would follow the normal `git flow` cycle of `develop > release > master`. The `release` could even be pushed to an _integration testing_ main QA url for last minute testing of all the *approved* features working together. – Hugo Ferreira Jul 10 '15 at 18:50
  • 1
    @HugoFerreira, thanks for reply! The client's infrastructure, and who is doing the testing, doesn't allow for multiple instances for testing. They only have qa.site.com, and live.site.com. They want to be able to test multiple small features at the same time on qa.sites.com. (PS. they are very slow to test some features). I know this is not ideal, because when moving one feature to live, the feature hasn't been tested in isolation / proper integration testing. But this is what they want. Is there an appropriate git process for this? You think we should keep with our described process? – David Smit Jul 13 '15 at 08:12
  • 1
    @DavidSmit, we are currently in a similar situation. Since it's been 4 years from when this question was posted. Could you please share the details of what you did to resolve this, maybe post an answer to this question? – Rithin Chalumuri Dec 11 '19 at 20:59

2 Answers2

3

After 4 years I will try to answer my own question. Although the other answer from @AlBlue is 100% the correct way of doing it, its not always possible.

Here are four Gitflow options to allow for a separate test environment, and allow for only specific features merged to be merged into master:

  • As mentioned in the initial question, create a separate branch(es) for integration testing, and merge each feature into this branch to be approved. More information can be found here Git branching model strategy . Downside is you will have lots of branches, I am not a fan of this solution if the other options are possible.
  • Cherry pick: merge into develop often, do integration testing on develop, once testing is approved, cherry pick features that should go into the release/master. (Haven't tried this but seems like a mission)
  • Use feature switches (As Alblue mentioned)
  • "Fix your process so that you decouple the git merges to master with the customer testing" - exactly as AlBlue said in his answer. This is now our preferred option because we have our automated deployments sorted now. For each feature a seperate hosting environment can be created with a click of a button (Azure devops + Azure hosting), so each feature needs to be tested before being merged into develop.
David Smit
  • 709
  • 1
  • 11
  • 30
2

Fix your process so that you decouple the git merges to master with the customer testing. If they want to be able to determine whether features should be live or not (and request that they are not present) then either they need to be part of the discussion to merge to develop, or you should use feature switches to allow you to deploy the feature but to be able to turn it off so that it appears if it is not there.

AlBlue
  • 20,872
  • 14
  • 63
  • 85
  • 2
    Thanks for the feedback! Hope I understand your answer, but we currently we would like to keep our release strategy as simple as possible (plain feature branching). We are quite new to git, and don't know if we would want to implement feature switches (_broke/dark code in production_ seems scary). As HugoFerreira pointed out, a **feature** should only merged into **develop** once fully tested. And for something to be fully tested at our client, it needs to be signed off by a tester on qa.site.com, which might contain multiple features in testing. Then we merge only that feature into develop – David Smit Jul 13 '15 at 08:29
  • In that case, stay with what you had before git. – AlBlue Jul 13 '15 at 08:59