This post lists some advantages and disadvantages of the two Git branching models known as GitFlow and traditional environment-based branching where a separate branch exists for each server environment (dev, test, uat, prod/master). <!–more–>
The one major advantage of env-based branching is that there is no overhead in collecting a set of changes and preparing an artifact for deployment because branches match environments. {: .notice–info}
Gitflow
- Good for release based work (e.g. “We are working towards v3.0 which includes a known set of features and improvements to be made public mid-June.”)
- Dependency management in Nexus/artifact repository (e.g. one app depends on v1.9.23 of a custom javascript library, when that library changes we want to upgrade the app by bumping the version number it is referencing in its dependencies list.)
- Instant developer feedback using Jenkins and automated tests. Allows for instant feedback by executing test suites against feature branches, isolated from other features). “Fail fast on your personal branch, not affecting anyone else”
- Allows parallel work and eliminates dependencies between developers.
- Allows parallel testing and deployment of releases into any environment (this convenience comes at the expense of some overhead due to release management process)
- It is difficult to deploy a set of changes into an environment without some management overhead. A release branch is created and a new software version assigned. It is not a simple “build branch and deploy” if you must be selective about what to include in each environment). This creates immense flexibility, however it offers no benefit to BAU work.
- Good for large teams
Environment Branches
- Follows Dev -> test -> uat -> prod/master
- No overhead in collecting a set of changes and preparing an artifact for deployment because branches match environments. (building UAT branch means the artifact contains all code changes that are supposed to go into UAT). (this convenience comes at the expense of flexibility)
- Good if we do not care about formal software versions and there are no dependencies between applications
- Better for BAU work
I found GitFlow overly complex for BAU support work where enhancements and defect fixes are rare and must follow the approval process.
A strange, strange model
I learned today about another model where there are different versions of each environment branch labelled A, B and C. For example, test-A, test-B and test-C. The advantage of this is that you can prepare different releases in parallel and only deploy one at a time to the respective environment. (Choosing either A, B or C). It comes with code logistical problems regarding merges and keeping code up to date (can't comment on this for the moment).
