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
• • •
Missing some Tweet in this thread? You can try to
force a refresh
So, here's my contrarian take on Why Trunk-Based Development Is Great But Probably Won't Work For You. Buckle up, it's a long one.
From time to time I talk about, or boost someone else's discussion of, "classical" continuous integration/trunk-based development/push-to-master/whatever. I do this because I've personally worked like this and I genuinely think it's a marvelous way to write software.
I've also, at this point in my career, failed—a bunch of times!—to bring this technique into practical use on the teams and organizations I've worked with. As a result, while I still do it myself, I don't focus as much on encouraging it in others.
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