Difference between revisions of "How to Avoid Branching"

From CitconWiki
Jump to navigationJump to search
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Problem: ==
+
== Problem Statement ==
  
 
Best practices for Trunk-Based Development
 
Best practices for Trunk-Based Development
Line 5: Line 5:
 
Goal is Continuous Integration
 
Goal is Continuous Integration
  
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 21: Line 21:
 
100s of developers, with a big legacy codebases
 
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: ==
+
The business wants to be able to cherry-pick features.
  
Baz
+
Can find yourself in an endless "refactoring" project.
 +
 
 +
Without a "prod-like" environment, there can be a resource contention that won't be solved by trunk-based development.
 +
 
 +
Moving to virtualization, like cloud, can be scary for companies because they "lose control".
 +
 
 +
Management can be reluctant to let a small group of people work on one thing.
 +
 
 +
== 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.
 +
 
 +
From the book "Code as a Crime Scene", they write that the area of the code that changes most frequently is probably the area that should be redesigned.
 +
 
 +
Use the Strangler Pattern to gradually improve the legacy codebase.
 +
 
 +
Have to build trust within the organization. Trust can be easier to gain with Continuous Integration and Continuous Delivery automating all the steps.
 +
 
 +
Report the amount of wasted work, i.e. features that never get picked to be released.
 +
 
 +
"Stop starting, start finishing."
 +
 
 +
Focus on "system flow" optimization instead of resource optimization.
 +
 
 +
Flow Lab is a simulation game to investigate system flow variables.

Latest revision as of 02:00, 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.

The business wants to be able to cherry-pick features.

Can find yourself in an endless "refactoring" project.

Without a "prod-like" environment, there can be a resource contention that won't be solved by trunk-based development.

Moving to virtualization, like cloud, can be scary for companies because they "lose control".

Management can be reluctant to let a small group of people work on one thing.

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.

From the book "Code as a Crime Scene", they write that the area of the code that changes most frequently is probably the area that should be redesigned.

Use the Strangler Pattern to gradually improve the legacy codebase.

Have to build trust within the organization. Trust can be easier to gain with Continuous Integration and Continuous Delivery automating all the steps.

Report the amount of wasted work, i.e. features that never get picked to be released.

"Stop starting, start finishing."

Focus on "system flow" optimization instead of resource optimization.

Flow Lab is a simulation game to investigate system flow variables.