-
Notifications
You must be signed in to change notification settings - Fork 0
Trunk based development manual
— Frank Compagner, Guerrilla Games
- Speed up development:
Can speed up development cycles by having all developers working on the same branch.
- Reduce risk:
Frequent integration of code changes can reduce the risk of merge conflicts or issues with dependencies, making it easier to identify and fix issues quickly.
- Promote collaboration:
As all developers work on the same codebase, It promotes collaboration among team members. This can lead to better code quality.
- Communicate with team members:
Communicate with their team members frequently to ensure that everyone is on the same page and aware of any potential issues or roadblocks in the development process. This helps to promote collaboration and reduce the risk of conflicts or misunderstandings.
- Check in frequently:
Check in code frequently to the trunk branch to ensure that their changes are integrated as quickly as possible. This helps to avoid merge conflicts and keeps the codebase up-to-date.
- Keep code changes small:
Aim to keep code changes small and focused to make it easier to review, test, and merge changes. Large code changes can be difficult to review, and may introduce more bugs and conflicts when merged.
- Write automated tests:
Write automated tests for their code changes to ensure that they do not introduce any new bugs or regressions into the codebase. These tests should be run as part of the continuous integration process.
- Review code changes:
Review code changes from their peers to ensure that the code is maintainable, readable, and follows established coding standards. Code reviews can also help to identify potential issues early in the development process.
- Use feature flags:
Use feature flags to enable or disable new functionality without having to merge code changes. This can help to reduce the risk of breaking changes and make it easier to roll back changes if needed.
- Keep dependencies up-to-date:
Keep dependencies up-to-date to ensure that the codebase is secure, stable, and maintainable. Outdated dependencies can introduce vulnerabilities or compatibility issues, which can be difficult to address later in the development process.
In trunk-based development, the main branch is the single source of truth and all developers are expected to commit their changes directly to it. In short, the decision to make direct changes on the main branch should be made when the changes are small, well-understood, and have been thoroughly tested and reviewed. Then when is the good time to create a new branch?
- Large or risky changes:
If you're making a significant change to the codebase that could impact the stability or functionality of the application, it may be a good idea to create a new branch for that work. This can help isolate the changes and make it easier to review and test them before merging back into the main branch.
- Feature development:
If you're working on a new feature or functionality, it may be beneficial to create a feature branch to develop and test the changes. This can help keep the main branch stable while you're working on the new feature and make it easier to review and merge the changes back into the main branch.
- Hotfixes:
If there's a critical bug or issue that needs to be addressed quickly, it may be necessary to create a hotfix branch to make the necessary changes and deploy the fix as soon as possible.
Naming branches is an important part of trunk based development, as it helps to identify the purpose of each branch and its relation to the trunk branch. Here are some guidelines for naming branches in a trunk based development environment:
- Use descriptive names:
Branch names should be descriptive and easy to understand, so that team members can quickly identify the purpose of each branch. Use names that convey information about the feature or issue being addressed.
- Follow a consistent naming convention:
Consistency is important when naming branches, as it helps to make the branch structure easier to follow. Consider using a naming convention that includes information such as the type of branch (feature or bugfix), the ID of the issue being addressed, and the name of the developer working on the branch.
- Avoid long branch names:
While descriptive names are important, it's also important to keep branch names concise. Avoid using overly long names that may be difficult to remember or type.
- Use slashes to show hierarchy:
If your project has a complex branch structure with multiple levels of branching, consider using slashes to show the hierarchy of branches. For example, a feature branch for a specific feature may be named "feature/add-new-functionality", indicating that it is a feature branch and that it is related to a specific functionality.
- Don't use special characters:
Avoid using special characters, such as spaces, underscores, or hyphens, in branch names. These can cause issues when working with some tools and can make branch names difficult to read.
flowchart TD;
A0(((Ok Let's code))) --> A1[Checkout Branch feature/something]
A1 --> A3(Code Changes);
A3 --> A4{fas:fa-vial Unit Tests};
A4 -->|Pass| A5[Create Pull Request];
A4 -->|Fail| A3;
A5 --> A6{fas:fa-code-branch Code Review};
A6 -->|Approved| A7(Merge to Main);
A6 -->|Request changes| A5;
B1[Github Actions: Build & Test] --> B2{Pass or Fail?};
B2 -->|Pass| B3[Deploy to Staging];
B2 -->|Fail| B4[Notify Developers];
B3 --> B5[Manual Testing];
B5 --> B6{Pass or Fail?};
B6 -->|Pass| B7[Deploy to Production];
B6 -->|Fail| B4;
C1[fas:fa-chart-line Monitor Performance] --> C2[fas:fa-comments Collect Feedback];
C2 --> C3[fas:fa-wrench Make Improvements];
D1[fas:fa-user User Feedback]:::feColor --> D2[fas:fa-clipboard-list Product Backlog]:::feColor;
D2 -->|Prioritize| D3{fas:fa-calendar-alt Sprint Planning}:::feColor;
D3 --> A0;
A7 --> B1;
B7 --> C1;
B4 --> D2;
C3 --> D1;
- Trunk-based development is an approach where developers work on the same branch and integrate changes frequently.
- To follow this approach, teams should integrate code frequently, keep branches short-lived, use feature toggles, and automate testing and deployment.
- Teams may need to create new branches for specific scenarios.
- When creating branches, it is essential to name them descriptively, follow a consistent naming convention, avoid long names, use slashes to show hierarchy, and avoid special characters.