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.
