The world of version control evolved in the last decade. We are an old-school engineer if we talk about the good times of SVN or Mercurial.
Git has been emerging in the open-source community to become the de-facto standards for development repositories. Its flexible model supports a distributed collaboration with a proven value with distributed architectures.
The concept of Git is different from its initial design with the idea of repository duality. We can easily fork a complete repository to implement our changes and incorporate them later into the original repo.
This is the power of Git.
With great power comes great responsibilities.
Voltaire.
The branching strategy is at the core of the software development lifecycle and engineering productivity. A solid understanding is required to avoid the merging nightmares we wanted to avoid in the first place.
We share our experience for evolving our branching model to maximize business value, developer experience, and engineering productivity. Over the technological aspect, the architecture, organization, and team specificities are fundamental requirements to consider.
Problems and use cases requirements
Defining well the problem is already halfway to solving it.
Outlining the problem we want to solve as well as its requirements is the first place to start. Even for engineering, we can be impatient to start coding and give life to our software.
If we step back from the existing practice, we need to achieve the following objectives:
- Deliver business value through software changes
- Accelerate the rate of changes to increase the business value delivered
- Guarantee the stability of the changes while we accelerate for our customers and operations.
Drilling down to the software delivery lifecycle aspects, we can ask ourselves “Why do we ever need branches?” or more directly “What would happen without branches?”
We will avoid going through a specific case to share common problems. The issues are down to one main reason: we need temporal decoupling of changes of the same codebase. There are many possible reasons, such as different release cycles for mobile app and their stores or long internal UAT cycle.
We need to keep this constraint in mind because our branching solution needs to be minimal. We usually do not need the most used, à la Mode, or by default in organizations.
The structuring requirements of the branching solutions we consider are:
- Maximize the engineering productivity with fast feedback loop composed of minimal steps and friction
- Provide a satisfying developer experience in the development flow steps
- Have a very reliable and efficient process for the mainstream cases, and one to manage the exception
- Support quality processes such as peer review or quality gates
- Separation of the build, deploy and release stages
The other considerations were to use Git as a chosen versioning management system while not jumping on the bandwagon on a Gitflow model.
Pitfalls and Anti-patterns of branching strategies
Talking about Gitflow, understanding where it comes from gives valuable information. Gitflow emerged to support a centralized development model around a shared codebase. Organization, engineering culture, and tooling are essential supporting factors. Those elements of contexts created the need for various branches to decouple the different stages of the build, deploy and release.
Why is it important to understand the branching model context?
Because we probably don’t need Gitflow for many situations. We can easily bypass an accurate assessment. Many other models exist in the ecosystem, such as GitHub Flow, One Flow, trunk-based development, master/production, etc.
We don’t have space here to dig into every model and its respective pros and cons. We can retain the process to structure our choice of branching model:
- What are the critical applications we need to evolve in line with our business strategy?
- How that software is going to evolve in the coming months? (e.g., If they change their architecture, this is structuring)
- What do our engineering organization, culture, and collaboration mechanisms incentives? Do we use a mono or multirepos model?
- Then for each application, what is the rate of changes, architecture style, and the ratio of developers collaborating simultaneously on the codebase and the same piece of code?
Based on this analysis, you can identify the significant use-cases and supporting branching models for your different contexts. For the stake of engineering management, one or two models per context are recommended from our experience. We followed this guideline in our context, sharing it in our next article.
Daniel Olival