Branching

The practice of maintaining multiple development lines based on a common history within a single version control repository.

Useful for:

• Experimenting with the implementation of new features
• Undertaking a substantial reorganization.
• Supporting a specialized variant to an application.
• Creation of a release.

Different branching practices can be combined into a branching strategy for a team.

Trunk Based Development (TBD)

Trunk Based Development (TBD) is a software development strategy where all developers commit code changes to a single branch known as the “trunk”. This approach minimizes the complexity of merging and maintaining multiple branches by encouraging small, frequent, and incremental updates directly to the trunk. TBD promotes rapid integration and testing of changes, ensuring that the codebase remains stable and deployable at all times. It requires a high level of discipline and automated testing to successfully manage and integrate contributions efficiently.

• Clearer visibility of progress on project.
• Reduces risk of merge conflicts.
• Requires developers to break changes to master down into smaller increments.
• Can increase risk of broken code in master.

Feature Branching

Feature branching is a version control strategy where developers create separate branches for each new feature or task. This allows them to work independently without affecting the main codebase (often called “master” or “main”). Once a feature is complete and tested, it is merged back into the main branch. This approach isolates development work, minimizes conflicts, and enables continuous integration by allowing features to be developed, tested, and reviewed in parallel before they are integrated into the main project. It:

• Allows developers greater freedom to develop new features in isolation.
• Is more convenient for managing code reviews.
• Encourages longer periods between integration

Feature Branching in CI

In its traditional form, Continuous Integration (CI) (CI) discourages the use of branches, advocating instead for developers to make small, frequent changes directly to the trunk. However, this can be impractical for some teams, particularly when experimenting with longer-term or high-risk features.

Use of Feature Branches in CI

Feature branches allow teams to work on new functionalities separately from the main codebase, helping to maintain stability in the trunk while experimenting. These branches can be kept in sync with the SCM repository, providing a structured way to manage experimental and risky developments.

Strategies for Integrating Feature Branches with CI

When incorporating feature branches into a CI environment, several strategies can be employed to manage their interaction with the trunk:

1. Frequent Merging: This strategy, preferred by CI purists, involves regular merging from the trunk to the feature branch. This ensures the branch does not diverge significantly from the trunk, minimizing integration issues when the feature is ready to be merged back.

2. Medium-term Management: Best for medium-term branches with low uncertainty. Regular merges from the trunk ensure that updates are integrated into the feature branch without impacting the trunk.

3. Long-term Divergence: Allows the branch to diverge significantly, providing the necessary freedom to explore high-risk changes. This approach is suitable for features that require extensive testing and development before integration.

4. Branch as Trunk: In some cases, a feature branch may become a separate trunk for an alternative version of the project. This is useful when the project needs to support multiple customer requirements simultaneously while maintaining a similar codebase.

Conclusion

While CI traditionally favors direct updates to the trunk, feature branching can offer valuable flexibility for teams dealing with complex features or needing to experiment safely. The key is to manage these branches effectively within the CI framework to ensure they contribute positively to the project’s overall goals.

Staging Branches

Staging branches are an integral part of the software deployment process, acting as an intermediary step between development and production. In this setup, once features are developed and initially tested in feature branches, they are merged into a staging branch. This branch reflects the candidate for the next production release and is deployed to a staging environment that closely mirrors the production setting. This allows for extensive testing and validation under conditions that simulate real user interactions, helping to identify and resolve issues before the changes are released to the public.

By using staging branches, teams can ensure that new releases maintain quality and stability, minimizing disruptions in the live environment.

Allows changes to be tested in a user acceptance testing (UAT) environment before go live.

• Changes can’t be merged directly to deployment - must pass through staging first.
• Some teams now configure a UAT environment for every feature branch (each feature branch is also a staging branch)

Naming Conventions

Following conventions for common branches enhances project maintainability:

• master/trunk
• uat, staging or preprod[uction]
• deploy[ment] or prod[uction]

Use a hierarchical naming strategy for features branches, e.g.

• feature/webapp/splash
• feature/mobapp/login