Changes

First suggestions

  • Change the “merge to Stable” strategy
  • New development Branch (Trunk) based on Stable
  • Keep Trunk clean
  • Every new release to QA is a full merge os the development branch to the Stable branch
  • Encourage the use of branches for experimentation or breaking updates
  • Branch-When-Needed strategy vs Feature-Branch
  • Development needs + QA needs
  • Feature Toggles vs Feature-Branch for breaking features
  • Development to Stable stabilization

New branch structure

  • QA requires a Stable branch for the testing releases, so the Stabel branch remains as is since it is the “Production Ready” branch.
  • Trunk is too unstable and messy to be used as a base development branch, so it should be put aside in favor of a new development branch that should come out of the Stable branch and should return to it on every and each new release as a whole, with no more cherrypick of commits by the developers.
  • It is each developer responsibility to guarantee the stability of the development branch by all means available. E.g.: writing and/or running tests and making sure that every critical test pass, make sure that the solution can be built without any problem before every check-in.
  • If a developer breaks the build it is his/her responsibility to make it work again.
  • The merge meeting focus is to ensure that the new version is working and pass all the tests, and make sure that all the tickets related to this new version are still working on the new stable version.
  • The merge from the development branch to the stable one is made by the end of the development cycle/week and the full branch is merged back into the stable.
  • The developers should use any means one sees fit the goal of not break the stability of the development branch and not introduce any new bug or unfinished feature on the new stable build. E.g.: New temporary development branch (aka Feature Branch), feature toggles to exclude any unfinished features from the build process.
  • In the case of the developer opt on using a separate branch for his/her development (aka Branch as needed strategy) he/she is the sole responsible for maintaining the branch in sync with the mainline (development branch) and to solve any kind of conflict (of content or tree) before merging back to the mainline.

References

Feature toggle

  • https://martinfowler.com/bliki/FeatureToggle.html
  • https://martinfowler.com/articles/feature-toggles.html
  • https://www.pluralsight.com/courses/dotnet-featuretoggle-implementing

Feature Branch

  • https://martinfowler.com/bliki/FeatureBranch.html
  • http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html

Branch by abstraction

  • https://martinfowler.com/bliki/BranchByAbstraction.html

Continuous integration

  • https://martinfowler.com/articles/continuousIntegration.html