Continuous Integration: That’s Not What They Meant • Clare Sudbery • GOTO 2023

This presentation was recorded at GOTO Amsterdam 2023. #GOTOcon #GOTOams

Clare Sudbery - Technical Coach @SudberyClare

RESOURCES

ABSTRACT
Many teams are practising continuous integration, or at least that’s the language they use. There are other terms in use too, such as continuous delivery and continuous deployment. The exact distinction between these terms depends on who you ask. But the big question is, just how continuous is it really?

Trunk-based development (TBD) is a powerful yet under-used technique for tightening the user feedback loop, lowering risk and minimizing the gap between coding and deployment. It’s a major component of good deployment practice, and many argue that anything other than trunk-based development does not technically qualify as continuous integration. But many developers are either not sure what TBD is, or do not feel able to use it.

This talk uses examples to explain the benefits of trunk-based development, and gives practical advice on how to make good use of the technique. [...]

TIMECODES
00:00 Intro
00:14 Jez Humble's continuous integration test
03:24 CI vs CD
04:26 TBD = CI
05:30 TBD: Better, faster, happier
07:16 Storytime
15:03 Dan Able quote
15:35 Kief Morris quote
16:55 Dragan Stepanović quote
18:49 Dave Farley quote
22:06 Review code base at regular intervals
26:50 Get help
28:58 Ensemble programming
31:35 Minimize dependencies
35:30 Trisha Gee quote
36:35 CTBD (Continuous trunk-based dev.)
37:15 Conclusions
38:31 Summary
39:13 Feature flags
43:17 Outro

Download slides and read the full abstract here:

RECOMMENDED BOOKS

#ContinuousIntegration #ContinuousDelivery #ContinuousDeployment #TrunkBasedDevelopment #PullRequests #CodeReview #EnsambleProgramming #MobProgramming #ClareSudbery

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

Good point that you can get from this talk is that you do trunk based development ONLY when you trust all of your developers and have good automated testing. I would hate having to revert junior changes every day.

[wildpett]

Excellent talk: Review the whole holistically - the area you are interested in --- this is much more efficient

[alexi]

so new so fresh =) oh wait, Simpsons already had it... a long time ago... and then git was introduced...

[mrjaimisra]

Really nice overview… as someone who has never worked in an org that practices trunk-based development, I’m eager to join one, and one day hopefully lead a team where I get to fully explore these ideas. One thing I’ve noticed is that the sum seems to be greater than the parts, in that these ideas really bear fruit when practiced in concert with one another. It can just be so challenging to find people who are willing to try out practices that feel unfamiliar, like TDD and pair programming, even if you swear until you’re blue in the face that the best work of your career has been borne out of that type of workflow.

[CuriousCauliflowerX]

Talk: trunk based development makes developers happy
Meanwhile cited dora report: trunk based development significantly increases burnout 💀

[gokukakarot]

Reasons for not working at Thoughtworks.
- Pair programming is like living in an Indian family, with no sense of privacy. Rarely this leads to deep work.
- Unable to understand, writing integration tests are more useful. Its like oh you want to write a sum function? First write a test.
Some devs I have worked, will write tests and assume their code works, push it to remote only to be surprised when it fails with an actual API call.

There will always be points of time where Merge Conflicts would come up, and the worst part is, its generally left upto the developer whose branch the merge failed, instead of a collaborative effort.
I mean when you have to explain to a bunch of intelligent audience what a regression test is, and how to run tests, you know its outta hands.

[troyrose]

The note on feature flags is a bit confusing and contradictory....
I mean - all developers, all the time should be running with %100 of the features turned on time but, what, write modules, but hide stuff from the user - with what - feature flags?

I see some major security implications by putting incomplete code into production this way.

[kocot.]

I find there is much more friction when you find some a problematic piece of released code than if you spot/were pointed out to it in the PR review. If that caused distrust in the team, there are other problems within that team. There are projects where code reviews are pointless and bring no value, in others they are priceless and save tons of money and stress. The ecosystem is just much more complicated than "let's do TDD/TBD/Scrum/whatever overhyped acronym"

[kocot.]

A bit weird how she moves from 'Big PRs are impossible to review, don't do that' to 'review whole code base/areas'. Also post-factum reviews, even though valuable, can't prevent changes before they happen. Good luck undoing some schema or infrastructure changes and while automated tests can prevent bugs they can't verify if developer understood the feature well. Local testing might not be possible besides simple unit tests and those are already understood to have limited value.

Pair programming on the other side is completely delusional IRL. It's super effective for 20min after which you become completely passive. It's also draining and impractical, even ignoring the remote work and timezone issues. Plus none of those practices is exclusive. If you pair-programmed something you can merge PR immediately together. If you can't or the peer wants to recheck it on his own screen/IDE, he can do it.