Difference between revisions of "How to Avoid Branching"

From CitconWiki
Jump to navigationJump to search
Line 5: Line 5:
 
Goal is Continuous Integration
 
Goal is Continuous Integration
  
Really we want Faster Feedback
+
'''Really''' we want Faster Feedback
  
 
== Complications: ==
 
== Complications: ==
Line 22: Line 22:
  
 
Branches allow you to circumvent fixing underlying issues in the organization
 
Branches allow you to circumvent fixing underlying issues in the organization
 +
 +
== 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.
  
== Potential Solutions: ==
+
You might be fine with a well-functioning branching workflow. Why change? Is this the biggest problem to solve?
 
 
Baz
 

Revision as of 01:27, 18 May 2019

Problem:

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

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?