Rant time: today I'd like to talk about feature branching and GitHub—how we got here, what they are (and aren't) good for, why that matters, and what you can do instead. Join me, friends! /1
First, a definition: "Continuous Integration is the practice of merging all developer working copies to a shared mainline several times a day." That's from about 1998(!). en.wikipedia.org/wiki/Continuou… /2
That's what CI is: developers merging to master, often working in pairs, and shipping artifacts, _at least_ once a day. Here's what it's not: a piece of infrastructure, something your DevOps team does for you, or running tests against your feature branches. /3
Why talk about CI? Because most teams who feature branch aren't CIing. It's a process, not a tool. It is something that you as a team choose to do, or not. You don't need a CI server to do CI. You can have one and not do it. /4 jamesshore.com/Blog/Continuou…
This definition has shifted so dramatically that advocates of the original practice had to coin a term—Trunk-Based Development—to capture and refine its essence. But there's a story in that term: the word "trunk" refers to Subversion. /5
So what happened between SVN and now? Git. More to the point, GitHub, which has probably done more than any piece of software now running to change the way teams think about software collaboration. Not always for the better! /6
GitHub's great for OSS. Open-source software presents a difficult set of collaboration problems: projects draw contributions from people who are widely distributed by both geography and time and have wildly different levels of experience, context, interest, and commitment. /7
OSS software development therefore makes sense as an asynchronous, big-tent process. Code is submitted and reviewed intermittently. People can reasonably work on somewhat different copies. Integration can be safely deferred. /8
All of you who work full-time on teams that sound like that, feel free to leave the room. This rant isn't for you. For the rest of you, here is an angry puppy. /9 gph.is/190PZ6y
However, most paid teams are the opposite: membership is well-defined, members are vetted and (hopefully) mentored, and everyone's being paid to show up, physically or online. /10
And many of those paid teams and larger orgs now adopt a feature branch collaboration model as a matter of course, and students are being taught in code schools that it's The Way—they'll use it in industry, so best learn now. /11
This is nuts. When full-time teams adopt, wholesale, a software development process built for casual ones, it doesn't come for free. There are tradeoffs! Some downsides, even! Viable alternatives exist! /12
Some tradeoffs that might not be visible: Deferred integration slows or delays refactoring. The review cycle for PRs may waste time in your shipping process. PR review is a lower-bandwidth collaboration model than pairing (for better or worse). /13
CI/TBD isn't magic, but the definition matters: it's what you'd arrive at yourself if you committed relentlessly to working incrementally and tightening every last damn feedback loop in your development process. That's hard, but it's not impossible. /14
Git may ship with a ton of features, but no one's forcing you to use them. Here's how I do trunk-based development with Git: `git commit && git pull --rebase && make test && git push`. You know what I never need? A branch visualization tool. /15
Reminder: /16
Reconsider your feature branches. And git-flow is bonkers. /fin
PS1: Jez has been talking about this for years. The @jezhumble/@martinfowler tongue-in-cheek Continuous Integration Certification article covers much the same ground, better and funnier: martinfowler.com/bliki/Continuo…
PS2: There's actually a lot more to be said about trunk-based development; credit goes to @paul_hammant for championing, refining, and documenting the practice at trunkbaseddevelopment.com. It is worth your time to read it.
PS3: The eagle-eyed among you will have observed that I'm simply restating XP values; this is not by accident.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Brian Guthrie

Brian Guthrie Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @bguthrie

27 Nov 17
Today I'm going on a rant about the term DevOps. Join me, friends! Here's the rant: the term DevOps originally had a completely different meaning from how it's now commonly understood, and I'd like to talk a little bit about why that matters, and what you can do to change it. /1
First, a definition: "DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality." That's from 2008. en.wikipedia.org/wiki/DevOps /2
That's what DevOps is: a set of practices that encourage continuous integration into production. Here's what it's not: a job title, a software tool, a team name, or magic enterprise fairy dust. No practices, no DevOps. /3
Read 18 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!