Difference between revisions of "How to Avoid Branching"
PaulJulius (talk | contribs) |
PaulJulius (talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | == Problem | + | == Problem Statement == |
Best practices for Trunk-Based Development | Best practices for Trunk-Based Development | ||
| Line 7: | Line 7: | ||
'''Really''' we want Faster Feedback | '''Really''' we want Faster Feedback | ||
| − | == Complications | + | == Complications == |
In monolithic codebases, it's hard to make quick changes | In monolithic codebases, it's hard to make quick changes | ||
| Line 23: | Line 23: | ||
Branches allow you to circumvent fixing underlying issues in the organization | Branches allow you to circumvent fixing underlying issues in the organization | ||
| − | == Potential Solutions | + | Emergent architecture, i.e. not designing your code up front, can cause a codebase that is even harder to do trunk-based development. |
| + | |||
| + | |||
| + | == Potential Solutions == | ||
A lot of places could do trunk-based development, but there is resistance like "people will break things" all the time. We have to switch first, experience some pain, but usually shorter than usual. | A lot of places could do trunk-based development, but there is resistance like "people will break things" all the time. We have to switch first, experience some pain, but usually shorter than usual. | ||
| Line 32: | Line 35: | ||
Shorten your branch lifetime. The shorter-lived branches are one step closer to trunk-based development. | Shorten your branch lifetime. The shorter-lived branches are one step closer to trunk-based development. | ||
| + | |||
| + | Merge from your branches to trunk, frequently. Or perhaps, merge from trunk to your branch, frequently. | ||
Revision as of 00:35, 18 May 2019
Problem Statement
Best practices for Trunk-Based Development
Goal is Continuous Integration
Really we want Faster Feedback
Complications
In monolithic codebases, it's hard to make quick changes
Team members need to have the skills to make the changes
The mindset gets in the way of people making a change from one monolithic build
I want refactor mercilessly
I want to release rapidly
100s of developers, with a big legacy codebases
Branches allow you to circumvent fixing underlying issues in the organization
Emergent architecture, i.e. not designing your code up front, can cause a codebase that is even harder to do trunk-based development.
Potential Solutions
A lot of places could do trunk-based development, but there is resistance like "people will break things" all the time. We have to switch first, experience some pain, but usually shorter than usual.
You might be fine with a well-functioning branching workflow. Why change? Is this the biggest problem to solve?
Fix the smallest "ouch" that the team feels at the moment...eventually trunk-based development will come up.
Shorten your branch lifetime. The shorter-lived branches are one step closer to trunk-based development.
Merge from your branches to trunk, frequently. Or perhaps, merge from trunk to your branch, frequently.
