Top 10 Rules For Continuous Integration

In this episode Dave Farley introduces his "10 Rules for Continuous Integration” - rules to organise a team to practise this vitally important aspect of modern software engineering. Dave was practising a version of CI in the early 1990s but refined his approach at ThoughtWorks in the early part of this century and is now seen as an expert in this field.

Continuous Integration is more than just build automation. It also demands a change in the way that software development teams organise their work and, when practiced well, introduces a more disciplined approach to software development.

This disciplined approach is even more important when practiced as a component of a Continuous Delivery Deployment Pipeline (CICD). Before Kent Beck introduced CI projects failed simply because teams couldn’t merge their work together. This is not a small change, and Continuous Integration is a cornerstone of any effective CD approach.

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

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

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

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

[PatriceStoessel]

0:00 introduction

*continuous integration*
6:28 1. Always run commit tests locally before commiting
8:01 2. Wait for the results !
8:44 3. Fix or revert failures within 10 minutes
9:51 4. If a team mate breaks the rules, revert their changes
10:30 5. If someone else notices you caused a failure before you notice, it's a build sin !
11:40 6. Once commit passes, move on to your next task
12:09 7. If any test fails, it is the responsibility of the commiter
13:02 8. If it is unclear who commited a failure, it is the responsibility of everyone who may be responsible to agree who will fix the failure

*continuous delivery deployment pipeline*
14:35 9. Monitor the progress of your commit
16:20 10. Address every pipeline failure immediately

16:53 ending

[Locomamonk]

I've always heard these terms and philosophies but you're the first one to put these into actual concrete examples of what they mean and how to adapt to these, and I understood them perfectly. Thanks for that!

[edgeeffect]

Years ago now, I set up a Bamboo server at our company using the meagre resources that were made available. It took about 10 times as long to compile on the server than running a clean build locally. It could have been as much as half and hour between commit and build... and we didn't even have a test-suite.
My number 0 tip would be "don't be stingy with the specification of your build server!" (several comments on here on the lines of "but our build takes over an hour to run" made me remember this).

[Rockem]

Few questions: 1. What happens when multiple commits are done in the same time? How do you revert? verify? 2. How would a developer know when he can rely on a change? how do we know when something is completely ready? 3. How can we review each other code remotely?

[tutunak]

This video should be used when the developer asks why do I have to test my changes locally? Very understandable and helpful.

[isaacdunstan]

I've just found this youtube channel and it's awesome. It actually presents software engineering as an engineering practice unlike so many other channels and I can tell that I'm going to have a huge binge-watch of all your videos. You're a great communicator and I love the work you're doing

[Ratstail]

Here's a thought for you: In video games, automated testing is almost non-existent. You can test the engine, the tools, etc. but the game itself needs manual testing. As a result, I'm actually very weak at automated testing, despite having many, many years experience.

[iluzjonista]

My current occupation is mostly building pipelines, watching them run, grow and wither. All while killing the wait time with your vids recently. Great insights. My fellow devs also get to understand all the ci/cd quicker with your vids it feels. Compared to me mumbling about it 24/7 at least. The lack of really low level examples make it so much more approchable to non Ops dudes.

[prq]

I wish I worked somewhere that thought about code development practices really at all, whether CI/CD or not. We use Jenkins, we nominally "do Agile" (we have a kanban board and have meetings that we label things like "Sprint Planning" and "Grooming" -- wow!), etc etc. But we really don't think about our how we're coding in this kind of way.

[scotthjackson]

at 02:43 reminded once again of Kubrick's famous edit in 2001: A Space Odyssey, the bone tool transitioning into the spaceship edit... here we are talking about how to develop software effectively and it is still about managing primate conflicts.

[elciomello]

Hello Dave, I Love your channel and videos.

I believe that a fast "CI pipeline" contributes to everything you said here, and I agree that the build and testing should be faster and done in 5 minutes (or else something is wrong eheh), but my doubt here is that today we have many other validations in the code that we consider in "CI", like SAST and Static Code Analysis, which makes that 5 minute time go up.
In this scenario, which is not a "5 minute Pipeline", what should you advise as best practices?
E.g. Should we run SAST in the CI pipeline and deal with the timing, given that we have value in getting this feedback sooner, or should we run this in separate pipelines after the CI pipeline and get our feedback as our deployment process progresses. is it evolving?

Once again, congratulations for the channel and videos with excellent content.

[Torsan]

Frequent rebases on main should ease some of the problems right?

It sounds to me like you're exchanging integration hell for developer hell. If someone merged broken (not compiling och failing tests) code to main, throwing the whole team off, I'd be pretty pissed.

If you very rarely have integration hell, is CI really needed?

Great content and I'm learning a lot.

[mikemegalodon]

Nice tips! Thanks, Except I don't really like the "finger-pointing" moment. How's about pre-merge validation that would run all the checks and make sure the main branch is always buildable?

[hunterwilhelm]

For point #7 If any test fails, it is the responsibility of the committer.
Should the committer then go and fix someone else's code that they aren't familiar with? What should they do?

[magdosandor]

How do I keep my tests under 5 minutes? I have only seen 20+ minute test runs in bigger projects.

[dgmstuart]

Genuine question: if you’re not able to get your test suite to run quickly enough that it’s reasonable to wait for it to pass (which in my limited experience is quite difficult for some teams to achieve), it sounds like this approach isn’t feasible?

[shellwhale]

How does all of this scale? Does that still work if you have hundreds of developpers on the same pipeline?

[BaoNguyen-ybqf]

As far I understand your video, it seems the term "Continuous Integration" has been watered down throughout the years to just mean "use a build server" :/, while the practices you've mention in this video has sort-of "renamed itself" to be called "Trunk-based development" these days :s.

[PieterWigboldus]

Instead of local tests, why not just small pr's, and wait for the required checks are green.
Locally tests for all code should not be required when you do it in the pipeline for the pr.
Reduce local resources, force the required tests, transparant for everyone.

[tj]

So use buildserver to build and start an autotest after each commit?