Version Control – Feature Branches, Beta Branches, and Scrapped Features

It is good practice to building your code only once and not per environment or branch.

Your GIT branches should not be directly connected to your environment stages.

The pipeline should be as follows:

develop > merge to baseline > build > upload to repo > deploy on dev > test > deploy to Staging > test > approve > deploy to 1 Prod > test > to n Prod.

Always using the same Artifact between promotions. All environments should be mirrors, with environment depend configurations being injected and minimised.

"promotion" is done by the deployment tool and not via GIT branch merging.

I also apply the QA to the full product and not to feature branches.

Testing branches in a vacuum will lead to integration or merging errors not being found and a false sense of security about the quality of the code. It can also create confusion with the Product Owner "I thought it was done and tested ? Why do we get errors now ?"

If you are not applying continuous integration, branching makes sense to split your hotfix from your already developed newer code. As such, simply feed the hotfix into the start pipeline and deploy it over the newest version.

Problems may arise if there are environment or data changes that are not backward compatible between the newest version and the hotfix.

In this case, one normally also includes all the environment and data configurations as a part of the "version" thus rebuilding the full environment every deployment.

This can be easily achieved if the servers are virtual or if they are provisioned via a configuration management tool.

Pratical example: vagrant file for each version. When you rollback from version 1.4.5 to version 0.5.6 you also rollback the vagrant configuration and thus the environment configuration.

While not my initial reference, here is an MSDN Team foundation Server best pratices and patterns: https://msdn.microsoft.com/en-us/library/dn449951.aspx I also advice the reading of the Addison-Wesley signature series books, Continuous Integration and Continuous Delivery

There are a few problems floating around in this that are causing issues that you are experiencing.

The first is the long running QA branch. Having a long running branch that is parallel to the development mainline may as a source of confusion because there are different efforts that need to be replicated in both the QA branch and the mainline. This means that either you are checking in fixes to the QA branch that need to be merged to the mainline (not a bad thing), or you are checking in to the mainline that gets merged into the QA branch (a source of possible bugs).

The other problem with the long running parallel branch is that it is possible for files to become perpetually out of sync. A code fix that never gets merged back, or a configuration needed for production builds that is never tested and part of the development mainline.

Next, you've got roles that are getting impinged on. This means that the packaging role (more on this later) is not getting sufficiently isolated.

In the git-flow model, the release branch is branched from development (not development merged to QA) and all fixes are checked into the release branch and then merged back to the development branch.

Some of the philosophy of branching can be found in Advanced SCM Branching Strategies (I consider to be an excellent read). This focuses on the roles that each branch may take on. The release branch takes on the packing role.

The packaging role is often confused with the accumulation or, more commonly, mainline roles. Once the intended development and maintenance have been performed and any accumulation has been done, it is time to prepare the code for release. Such an effort may not be trivial, requiring a team of release engineers and additional fixes beyond those already performed. The policy on a packaging branch is significantly different from that on a maintenance branch, as the packaging role suggests, only the changes necessary to make the product releasable should be addressed.

• Branch from the development point to the release branch. The release branch that QA builds from gets one branch and no merges from development.
  • If you want to go down that road, with consistent naming and hooks, it is possible to prevent a merge from being done into a release branch.
• Fix everything that needs to be fixed in the release branch and merge those changes back to the mainline.
• At the end of the release effort, merge the release branch into the "releases go here" branch and tag it as such.
  • Some sites don't have a "releases go here" branch and just leave the end of the release branch dangling with a tag.

One should seriously consider applying the entirety of git-flow in place. This isn't too far from what is being done currently and puts some discipline and consistency into what each branch means and how each branch interacts with others.