Why CI is BETTER Than Feature Branching

Continuous Integration and Feature Branching are both very popular ways of organising work in a development team, but they are mutually exclusive for most cases. This is counter to what many, maybe most people think. In this video Dave Farley explains the difference and why the two are largely mutually exclusive and why CI is technically the better approach.

Software engineering, any engineering, is all about trade-offs, the trade-off at the heart of CI is that to avoid conflicts our aim is to integrate our code with that of our co-workers as close to “continuously” as we can, that means that we can’t afford to wait until we are finished. If we have two, or more, copies of information and begin changing them, the copies will diverge. At some point they will reach a point where they are incompatible with one another, and so bringing them back together gets increasingly difficult. CI was invented to fix that problem this video explains how it does that.

-------------------------------------------------------------------------------------

🎓 CD TRAINING COURSES 🎓

📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses.

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
(Paperback version available soon)
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble

-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[CrossbowBeta]

Not merging for weeks is not called feature branching that's just working on a different project.

[TulioMoreira]

branching is like time travel, it's sometimes helpful but if you stay away for a long time the consequences are unpredictable

[xilconic]

I'm interested in what your opinion is on Code Reviewing practices, in light with your strong preference for CI workflow. Some companies I've worked at, have a pre-merge code-review process like Github's PR system that needs a review before being merged into trunk. A pre-merge code-review process or mindset would then only work in an environment that considers a pair-programmed changeset as properly reviewed? Would you consider a pre-merge code-review policy to be an impediment towards incorporating CI?
In companies that have a post-merge code-review process this problem doesn't seem to exist, but one would probably require an adequate level of (non)functional coverage in their automated tests to catch mistakes quickly, such that code-review is only needing to (ideally) focus on design. Are you therefore of the oppinion that a post-merge code-review process (or pairing as mention before) are two key processes to have in place for enabling CI?

[urbanofreitas]

Once more insightful thinking of how sw can better made.

Thanks Dave Farley.

Since this is a so difficult practice to get the teams and/or Devs to move to, if possible I would love a future video of how to start with it.

Something like what needs to be done from the beginning, and a possible adherence to other techniques, etc.
Thanks in advance.

[danielliebster]

Thank you for making the CD concepts presented clear and concise, that aspect pulled me in from busy, busy work. And much to my benefit :)

[tkjyxrb]

Yay! Finally I got an excuse for committing directly into master: it's called CI

[________w]

If you don't think a single developer working alone can benefit from feature-branching, I don't think you and I are talking about the same thing when we say the word "branch", which would certainly explain the discrepancy.

a "branch" collects units of work (commits) together. Each commit is the smallest change which works on its own. Each branch is the smallest change which justifies its own existence.
Within a branch, prior to integration, commits are not a commitment - they are rewritten / re-ordered regularly, as the discovery process continues. Integrating them doesn't make sense, because they aren't final yet. Forcing integration prior to the change being done makes the history unreadable because each change becomes separated from its justification. And of course, the one and only reason we're even using version control (instead of just sending each-other diffs against the last timestamped snapshot) is to keep track of *why* changes happen.

I think we both agree that integration needs to happen very regularly, but disagree strongly about the acceptable scope of both feature branches and commits. I don't want to be "more continuous" than the smallest justifiable unit.

I also disagree that "a branch which can't be integrated" is the same as "lost work", and I would have thought (based on your other video) that you would be a strong advocate against that sort of position. Sometimes code needs to be rewritten based on new information, and when that happens, it's always faster than writing the original code.

It really sounds like you're talking about traditional, long-lived branches, rather than feature branches.

As with so many discussions encountered on the Internet, I'm pretty sure I agree with everything you say, except for the specific terminology.

[YisraelDovL]

What about code reviews before closing an issue/feature?

[esra_erimez]

And Dave Farley said not to branch and there was no branching. And Dave Farley saw no branches, and it was good.

[oyeyipo]

Can you please further discuss the application of this in the context of open source software. Thanks

[dreamscometrueband]

I recently retired after 47 years in the field, slowly trending from coding to writing tools to version control to configuration management to as close as I could get to continuous delivery, which wasn't very close because I could not convince my teams of some key points. I am hugely enjoying your videos and your explanations, and thought I'd share a few observations from my time in the field.
1) I haven't heard you say this actual phrase, but some major luminary very early in the software world's development stated "Nothing of any significance has ever been accomplished by a team of more than 7". I've heard you express much the same idea, though, quite a few times. More people than that exponentially increases the chances of miscommunication about the design of the system.
2) I used to sort of half-heartedly suggest feature branches for extensive, disruptive, dangerous changes, but my teams always resisted it hard for the reasons that you clarify in this and the other videos about "don't feature branch"; essentially, merge hell will invariably result.
3) I worked in about 9 different shops that all claimed to be doing Agile Development. In one of them, they were actually doing Agile Development. In the others, they were indulging in rituals designed to fire off the buzz words managers wanted to hear, but these rituals usually were bumbled so badly they didn't do much good and in some cases were actually harmful, like when the boss was the scrum master without training and did most of the talking.

[bryanmartin]

One of the issues I have around CI vs Feature branching is more related to maturity. As far as I can tell, it works great when you have a stream aligned team working with a code base where most of the work happens in parallel. When you have a monolith, the problem with CI (for me) is that integration events become unpredictable. One team may be testing a set of changes, when another team commits a change that is automatically deployed. All of the tests cases that had been performed at have been invalidated as a result of the change. That's primarily why we've used feature branches in the past, to isolate changes just long enough to test them.

[whaisonw]

3:20 I often feature branch when I'm alone. That gives me the benefit of switching features when I get stuck and I can come back later. You may argue that I should comment the changes out or implement a software switch when rewriting a function. That can indeed be a solution and I admit that I haven't tried it yet.

[theaninova]

Hmm, I'm still not 100% sold... Sometimes CI sounds like a really great idea, but the problem also is what do I do when I approach larger refactorings (like updating dependencies to a new major with breaking changes) that take time and will leave the project in an unworkable state until completely resolved or changes that we are not sure if we should carry them through... How do really revert a series of commits in a CI world, where they are mixed in with other people's stuff.

[omarsuriel]

I think big take away we need to remember is: “Continuos integration works by limiting the time period and thus limiting the fan out of the cone of changes, this reduces the risk of a clash”. That makes me wonder, if we use feature branches but could somehow guarantee the time period of unchecked code is the same or less as not using feature branches and forbid branching of feature branches to avoid the cone, are feature branches still bad?

[MichaLipek]

How to use trunk-based development in a legacy system where there is huge technical debt and most of the code doesn't have good tests we can trust? How to ensure quality where each commit to the trunk can potentially break the system.
Of course, we try to write more tests and do refactoring doing some new feature, but writing tests is not always possible when everything is coupled together.

[JerzyToeplitz]

What to do with code review? I can't imagine that there is no place for it in Continuous Integration ?

[ws_stelzi]

Hey who doesn't like the smell of a merge conflict in the morning standup meeting? 😜🤔

[Phoenix_ZA]

There may be an issue with semantics;
TLDR; If we branch off of the trunk, but the branches are so small that several of them are PR'd in a day per person, does this still count as feature branching, or is it CI/CD as you describe?

I run a small team of 3, sometimes 4 people, and we never work directly off of the trunk (which is actually our staging branch, but that is another story), as we want it protected, and instead, we make what we call 'feature branches', which is often small break downs of larger features into tasks (so maybe we should call it task branches), small enough to complete at least one, but usually several of in a day.
We want the trunk protected as we want to review all the code via PRs before it goes into the trunk.
We do this so frequently, that merge conflicts are quite rare, and our CD pipeline is often backlogged near the end of the day.
In addition to this, we have small 10 to 30 minute (depending on what needs to be discussed) meetings throughout the day to discuss what we are working on and the direction we are taking, which helps avoid having to re-do a lot of work at PR.

This strategy involves, more frequent, but much smaller PR that requires very little comment.
Seems to be working great for us, except as the lead I need to work on getting my code reviewed by the other members more often and not just self approve.


So basically, does this workflow still count as CI/CD as you describe, because it's still frequent, or is it disqualified because we are not working directly off of trunk. And if it's the latter, is it possible to protect the trunk in any way in this workflow?

[FlaviusAspra]

Dave, I agree with what you say on so many levels. I am one of the people commenting on the other video. I would like to also refine my view. Please keep in mind, what I don't say explicitly is because I think we see things the same way.

Let's recap what was the main issue in the other video's comments: the beginners of the team. Beginners are a healthy factor in a team for other reasons than the quality of the code.

Technically, we tackle beginners by reviewing their code. Another reason to review the code is compliance. Either way, beginners will make mistakes that cannot be caught automatically, no matter how good your tests are.

Let's add one more to the list of things to keep in mind: we fully agree that things should be integrated as often as possible.


What we don't agree on is doing it at every commit.

This is literally insane, for the reasons I hinted above.

What we do instead is redefine the notion of a "feature". It's not an user story, but a subtask.

Let's take an example. The junior on my team has been working for almost two months on a user story which ended up having about 30 subtasks. So on average, he finished (and integrated) one feature every 1-2 days. The reality is, some features (subtasks) were easy even for him, so some features were half a day, while a few took him as long as a week.

I am fine with this, because we reduced the risk of breaking master, while also reducing the waste of effort (it was the beginner tinkering, so 1 week does not cost that much).

Keep in mind, most of the time we were integrating every 1-2 days.

We can also integrate all combinations of feature branches automatically and test them because since they're short-lived, there's less of them! We remove the branches after integration.

So roughly we have only as many branches as the number of people in the team.

Integrating at every commit would work only in a team of only seniors.