I’ve been testing out trunk based development for a few months, here are some of my initial thoughts. It was inspired by @davefarley77‘s series of videos on building pipelines and his “Don’t Branch”
Dave talks about setting up a pipeline with a series of quality gates. In the past, I never liked building pipelines, nor the tech behind them. I’d delegate all Ops work to the smart, energetic college kids we hired every year. My new job is a small company, meaning I have to set that up myself. I’m not good at Ops 😬.
I knew nothing about Gitlab nor its pipelines. I do know coding & testing, though. Within a couple weeks, I had basic pipeline for 2 repos: the web UI and the serverless API. Dave’s videos inspired me and gave me energy to persevere in new territory. Iterating by getting “something” working was productive and built the self-esteem.
The first thing I noticed was Amplify, AWS’s managed front-end deployment & hosting pipeline, gives you amazing controls over branch management & deployment. I used none of them. I didn’t have to learn them. So much work saved. Easier to reason about “what’s deployed” == “main”
As my quality gates got better, I started noticing my releases get less frequent because my pipeline was catching all kinds of errors. Skipped running tests? Pipeline won’t. Left debug logs in your code? Pipeline won’t allow that. I ensured to duplicate as much locally as possible to speed up development. This meant a bug in local code is easy to see in pipeline & vice versa; they’re running the same commands and seeing the same issues.
I managed to get API pipeline from code check in to production in under 10 minutes (yes, Jesse Warden had to use Docker, something I swore I’d never touch again), UI in 5 minutes. The UI uses AWS CodeDeploy (built into Amplify) and API uses 100% Gitlab. Both are using Serverless framework to deploy code (which is mostly CloudFormation behind the scenes which I’ve only had to break glass once on).
Last time I did trunk based dev was back at HBO when it was Subversion (SVN). Rather than communicate changes, we just checked as fast as possible to avoid being the person who has merge pain. Git thankfully makes this wayyy less painful & automated.
My first co-worker and I would just proactively inform each other on Slack if we checked in something and what it was. These… felt too frequent. Yes, being productive and checking but also a lot of “bot-like” Slack messages. Probably should automate that, too, to literally be a Slack bot.
Pair Programming worked much better. I’d drive or co-worker would drive, and zero need for code review; because we just did it working together. I’d either teach him Elm/ReScript/JavaScript/programming/CICD/testing/CSS/workflows, or he’d teach me stuff and/or find all kinds of bugs and misspellings in my code.
I’ve done pair programming before and mobbing twice that I can remember, but never as a “normal daily routine” like this. However, my 2nd co-worker, he likes to work independently. I haven’t figured out how to make this work there yet. For now we just inform each other of code changes.
This results in zero feature branches to review, delete, or setup pipelines for. All that is no longer work to do, or things to worry about. Instead, we just write code, push it, and confidently wait for the pipeline.
I’ve still got a lot to learn about Ops, Gitlab pipelines, AWS, CSS, etc. but never have I had this much confidence in myself and my tools. I really dig this trunk based dev, pair programming, and the simplicity, speed, and frequency of deployments.
It’s solidified my old consulting beliefs of “fixing to build” is most important thing. Other code bases I’ve seen with 30 minutes to 1 hour of build times, and no matter how good the coders, language, and tools… its’ still a mess because it takes so long to make a change that you’re not even confident in.
My goals now are figure out how to formalize pair programming with new teammates, balance that with those who wish to “disappear and create”, speed up the pipelines more, add some kind of formal tests in both pipelines, and get better at TDD in the UI (API is easier for that).
Additionally we only have 2 environments: On your machine, QA and Prod. I need to learn more about best practices here, and if devs really need their own environment. Again, this shows my Ops chops being at beginner level, but the tools are soo good now compared to years ago.
It’s hard everyone checking things often into a single branch at first, but pair programming solves the code review, the “learning about other parts of the code I’ve never worked in”, and Git solves the merging drama. I hope to get better at scaling this to more team members, too.
Cons/unknowns still exist: not testing first bit me, End to End testing even w/Cypress is hard, Amplify requires too many admin privileges negating my ability to use a monorepo, & I still haven’t figured out security + performance testing in pipeline. Lots to learn, but still productive.
Top comments (0)