Continuous Integration vs Feature Branch Workflow

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 then explains how to live in the CI world by describing three different approaches to keeping the software working as it evolves.

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 take that idea one step further into Continuous Delivery, then every change may end up being deployed into production, so we need to grow our software, through many small changes, committing multiple times per-day, and be comfortable that, at any point in that process, the software may be released into production. How do we use ideas like dark-launching, branch-by-abstraction and feature-flags to help?

RERERENCES:

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

🎓 CD TRAINING COURSES 🎓
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
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

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

📧 JOIN CD MAIL LIST 📧

[GuyRutter]

I’m a contract tech leader and came back to this video after recently joining a new team. I think it’s probably my favourite video of all of the excellent videos on your channel Dave. The kids game analogy is both perfect and hilarious and hence just the tool you need to trigger some self reflection in a team where some members are struggling to get the continuous delivery mindset. I must say thank you for this one. I’ve tried to pay it back as best I can and bought the library of books, many of which are part of my most quoted along with Brooks, Martin, Beck et al. Nice.

[alittlelightcse]

Best programming content on YouTube, can’t get this level of experience and amount of useful info anywhere else

[Crozz]

This assumes all my changes are always incremental. In practice I often tear down most of what I did after I've cemented the general idea. To introduce my initial ramblings to the team before I even know if it's the direction I want to go, sounds like a whole lot of work for nothing.

[adityaprakash]

We changed our process after this video few months ago and that instantly solved lot of code conflicts problems that we were facing and allowed us to visualize the progress of the day. Thanks a lot for the content

[msintal]

Im not even a programmer but, I'm loving this channel. Found it through Cyberpunk criticism. Very fascinating!

[CottidaeSEA]

The definition of continuous integration sounds like 10 developers coding live on the same computer but with different keyboards.

[andyd]

You are the programming mentor i was always looking for but never found. Well now you are here. Thank you for your videos.

[Thejasonlessard]

How do you do code review before a commit to the main branch if you are not branching and submitting merge requests ?

[mmick]

I just want to express my gratitude for your content. It’s really professional stuff. As a software developer myself, yours is one of the very few channels I can actually still learn from. Bravo!

[AlexAegisOfficial]

My preferred way of dealing with staying updated with feature branches is frequent rebasing, this also allows me to have a linear history instead of a git history looking like a weaved basket.

Gerrit is a very interesting Git host, it automates a lot of fiddling with branches to the point development can go on for months without even thinking of creating a feature branch. Because in Gerrit you work with patchsets (internally they are just branches where only the head is used, so it acts like a single commit, with all its history still available) and just "replace" commits, and you can do this as long as you like, rebasing it, running CI against it, until you merge it back to the parent branch.

[gregzoller]

Branching is valuable. Many times I use a branch for experimentl changes/refactorings that I’m not yet sure should ever be merged—at least until they prove themselves. If it doesn’t work out, I just delete the branch. Other times I use a branch to make significant refactorings I don’t want to disturb the main code, which is still moving. Its not always possible to think of work as a stream of small incremental changes.

[johnnyw]

I was about to write a comment on how this was clearly bullshit. I watched the video instead. By the end I got completely what you were saying, and it makes perfect sense. CI isn’t something you can dabble in, and this demonstrates the level of commitment required to do it right. But if the data says it’s the most efficient way of working, then it’s worth seriously considering. Thanks!

[Inversions]

Thank you for sharing this! When the video started I thought, "this is a terrible idea", but the methods you presented for safely dealing with partial features make a lot of sense. I think branches still seem to make sense for open source projects because of the distributed decision making process in the community. But inside a development team I can definitely see this being a lot smoother.

[henristahl]

At what point do you perform code review if you commit to trunk every 15 minutes?

[jefferygriffith]

I feel like this would have been better received if it had been about branch lifespan/scope rather than “don’t branch” since branching is the typical means of code review. It seems to me branch/review/merge often is compatible with the CI definition and provides the same benefits you describe. Thanks for the video!

[BigCarso]

So if Bob is working on the same file as me, then I'm supposed to pull Bob's changes every hour, understand why he broke my feature then rearrange my feature and break Bob's feature the next hour? Sounds like no fun. Never had a problem with merge conflicts and much prefer to have complete ideas to compare and merge.

[KevinBronsdijk]

Interesting topic. I believe that this is the way forward; however, one concern I have is related to code reviews. Im not worried about syntax relates issues; this can be automated using static code analysis. I'm mainly concerned about of the feature as a whole. 

When you make all your feature changes within a single branch, you will have a holistic view of that feature's design and implementation (something which can also be used as a reference). This is something which you will lose when committing directly to master.

Just wondering how you have solved this problem. Maybe it's as simple as tagging the commits with a feature id, but review tooling just isn't ready for this scenario.

[Miok]

This approach kinda assumes that no one makes mistakes. Imagine someone is committing every 15 minutes. After 2 hours someone realizes that there is a huge issue with the new code which affects everyone's ability to work on their own tasks. Writing tests won't always help. Things can slip through. Also writing tests that early is often times a waste of time because you don't even know what the final version will look like. Thanks for your video tho!

[ronaldomorillo]

If your feature requires changes to shared libraries and database schema, how would you handle potential breaking changes to other areas of the code if you don't isolate them by branching?

[beepboop]

Can't wait for all the supporters in here to get in the field and deal with the struggles this methodology lends itself to.

Hopefully they won't become cultists over this and one day will be willing to give branching a chance.