Release Branching¶

Context and Problem Statement¶

Assume that we have 2 versions of PSS®X application or modules out in the field: * v1.0.0 * v1.1.0

Now we want to prepare the next Release * v1.2.0

And in parallel work on new features for the overnext release, without a merge freeze on main

Following picture already shows, how this can be solved: Branches

Decision Drivers¶

Branching model should support:

• Teams can work in parallel.
• Gated releases with quality assurance/lead designer final approval.
• Planning for future releases.
• Supporting multiple past releases.
• Tracking features in a release.
• Dropping features from a release.
• Framework/infrastructure branches that do not correspond to a single feature.
• Tagged releases for auditing and traceability

Considered Options¶

• Git Flow
• GitHub Flow
• GitLab Flow
• Trunk-based development

Decision Outcome¶

Chosen option: "Git Flow" because,

• Parallel development and stabilization for release while developers work on separate branches..

Consequences¶

• It slows down the development pace by a lot. Often the developers that will review the code has an assignment for themselves, this means we usually have to wait for our code to be reviewed.

More Information¶

Git Flow¶

GitFlow enables parallel development where developers can work separately from the master branch on features where a feature branch is created from the master branch.

Afterwards, when changes are complete, the developer merges these changes back to the master branch for release.

This branching strategy consists of the following branches:

• Master (Main)
• Development
• Feature- to develop new features that branches off the develop branch
• Release- help prepare a new production release; usually branched from the develop branch and must be merged back to both develop and master
• Hotfix- also helps prepare for a release but unlike release branches, hotfix branches arise from a bug that has been discovered and must be resolved; it enables developers to keep working on their own changes on the develop branch while the bug is being fixed.
• The main and develop branches are considered to be the main branches, with an infinite lifetime, while the rest are supporting branches that are meant to aid parallel development among developers, usually short-lived.

Positive: - Most obvious benefit of this model is that it allows for parallel development to protect the production code so the main branch remains stable for release while developers work on separate branches. - The various types of branches make it easier for developers to organize their work. This strategy contains separate and straightforward branches for specific purposes though for that reason it may become complicated for many use cases. - It is also ideal when handling multiple versions of the production code. - The separation of branches allows for various levels of testing and validation. The release branches offer an extra layer of quality assurance before changes hit production.

Negative: - As more branches are added, they may become difficult to manage as developers merge their changes from the development branch to the main. Developers will first need to create the release branch then make sure any final work is also merged back into the development branch and then that release branch will need to be merged into the main branch - In the event that changes are tested and the test fails, it would become increasingly difficult to figure out where the issue is exactly as developers are lost in a sea of commits. - Indeed, due to GitFlow’s complexity, it could slow down the development process and release cycle. In that sense, GitFlow is not an efficient approach for teams wanting to implement continuous integration and continuous delivery.

GitHub Flow¶

GitHub Flow is a simpler alternative to GitFlow ideal for smaller teams as they don’t need to manage multiple versions

Unlike GitFlow, this model doesn’t have release branches. You start off with the main branch then developers create branches, feature branches that stem directly from the master, to isolate their work which are then merged back into main. The feature branch is then deleted.

The main idea behind this model is keeping the master code in a constant deployable state and hence can support continuous integration and continuous delivery processes.

Positive: - GitHub Flow is easier to understand and implement, making it a great choice for smaller teams or projects with less complexity. - The focus on keeping the main branch always deployable integrates perfectly with CI/CD pipelines, enabling rapid deployments.

Negative: - Because there’s no designated staging or pre-production branch, thorough testing before deployment can be challenging. - The emphasis on continuous deployment means that there is a possibility of unstable code being deployed if not adequately tested.

GitLab Flow¶

GitLab Flow is a simpler alternative to GitFlow that combines feature-driven development and feature branching with issue tracking

With GitFlow, developers create a develop branch and make that the default while GitLab Flow works with the main branch right away.

GitLab Flow is great when you want to maintain multiple environments and when you prefer to have a staging environment separate from the production environment. Then, whenever the main branch is ready to be deployed, you can merge back into the production branch and release it.

Thus, this strategy offers propers isolation between environments allowing developers to maintain several versions of software in different environments.

While GitHub Flow assumes that you can deploy into production whenever you merge a feature branch into the master, GitLab Flow seeks to resolve that issue by allowing the code to pass through internal environments before it reaches production.

Positive: - GitLab Flow combines the best of both feature-branching and environment-based branching, making it a more flexible alternative to Gitflow. - The branching strategy was designed with CI/CD in mind, allowing for seamless transitions between code development and deployment. - The fewer number of branches simplifies the development process, making it easier for team members to collaborate.

Negative: - To take full advantage of GitLab Flow, a well-defined CI/CD pipeline needs to be in place, which could require additional setup and maintenance.

Trunk-based development¶

Trunk-based development is a branching strategy that in fact requires no branches but instead, developers integrate their changes into a shared trunk at least once a day. This shared trunk should be ready for release anytime.

The main idea behind this strategy is that developers make smaller changes more frequently and thus the goal is to limit long-lasting branches and avoid merge conflicts as all developers work on the same branch. In other words, developers commit directly into the trunk without the use of branches.

Summarized the branching strategies¶

Workflows like Trunk-based development or GitHub Flow are the flow types that automatic processes more suitable.

On the other hand GitFlow is the exact opposite, it let you manage the content and the timing of your release manually via release branches.

It's a very different way of working that has it own set of advantages and inconvenient, just like any other.