Six-word summary: excellent tech-agnostic introduction to CI/CD
Quick rating: 5/5
Wow – even though I’m not a complete newbie to CI/CD, I think I learned something new every few pages. Or improved my understanding of something. Or questioned an assumption I’ve held for years.
Christie Wilson’s writing is conversational and pleasant, but that doesn’t mean the book is for kiddies – the 370 pages cover much more than just the basics. There’s loads of vocabulary, concepts, and fictional scenarios designed to highlight the incredible value each “step” of a CI/CD pipeline brings to a team.
I particularly enjoyed the “human element” woven throughout this book. Techniques and tools are introduced as solutions to specific problems familiar to developers and customers: painful middle-of-the-night calls, crunch around release, lengthy release cycles, long waits for features/bug fixes, and more. It’s not just a presentation of technologies, it’s a presentation of solutions.
Where I was starting from
Before reading this book, I would have described my understanding of CI/CD as “enough to get by on”.
I knew the gist of it as a result of working on teams using CI/CD: push a change, then the tests run on the build machine, and depending on the outcome, either merge the change into the codebase or fix what broke. The idea was to keep the codebase in an always-usable state. (Which was a huge step up from places I worked in the 00s, which were a mixed bag of manually kicking off builds, few automated tests, and a whole lot of “well it worked on my machine”.)
But I still felt like I only had a vague idea of how it all fit together. I wanted a better understanding of the underlying philosophies and goals. I also wanted to nail down some of the correct terminology for things (turns out it’s not “Jenkins is busted again”).
Length: 13 chapters, ~370 pages, lots of pics
Time to read: About 2 weeks of casual reading (a chapter every day or two)
Subjects covered: continuous integration/delivery/deployment, best practices, testing philosophies (unit vs integration vs e2e), “config-as-code”, typical pipeline structure, adding CI/CD to existing projects, dealing with flaky tests, test “noise”, some tech-specific stuff near the end (a quick tour of modern-day CD systems and version control systems), incremental feature development, dependency versioning, rollbacks, code coverage, shell scripting, parallelization…. and lots, lots more
I found the book surprisingly readable – this isn’t a dry tome of configuration or theory. The chapters flow nicely and build on previous ones. The diagrams, takeaway sections, and illustrations grabbed my attention in a way that just kinda pulled me through the pages.
What I’ve learned
The most surprising thing I “learned” was how many of my assumptions about releasing software were laid bare and challenged by this book.
- If releasing is painful, you should release more often.
- An ideal deployment frequency is multiple times a day.
- You don’t need to wait ’til the next new project to get started with CI/CD. Even if you can’t move all of a project to CI/CD, you can move parts of it – and doing so is valuable.
- Feature work can (and should) be merged into develop incrementally. (Not to sound clickbait-y but this one really shocked me. I’m more familiar with mega-PRs that contain the entirety of a new feature and about a thousand merge conflicts.)
I think it helped, also, that I recognized so many of my “real life” work teams in this book. I have definitely been on teams that do some combination of the following:
- tests that pass or fail randomly so we disable them
- tests that take way too long to run so we run them sparingly
- rolling out new features to everyone only to discover it’s broken and have to quickly unroll it out
- deployments that are done manually by some poor sucker
- processes/configs that live in someone’s head instead of in the codebase
- delaying a release because we’re scared of what’s in it
- merge a new feature only when it’s complete and includes 50+ changed files full of surprises and things that have to be updated and adapted to other in-progress work
- more stuff I’ve tried to forget
I wish I could send this book back in time to those teams 😅
Who this book is for
If you’re already working in DevOps or you’ve set up some pipelines yourself, then you probably know most of the stuff this book covers. There are some general references to real-life technologies in this book, but this book is more about the concepts and goals of CI/CD, not a tutorial you can follow (although after reading it, I felt like I was ready to dig into the tutorials and docs).
If you are early in your career or your company is just starting to talk about CI/CD and all you know is the acronym, then this book will be an excellent introduction to continuous delivery.
If you have a few years of experience and know of CI/CD (and maybe you’ve worked on a team that uses it) then you’re probably going to get a lot out of this book. A few topics will probably be familiar, but the rest of it will expand your CI/CD knowledge and give you a much broader and more organized understanding of a wide variety of continuous delivery topics.
I could also see this book as being really useful to product owners, managers, and other people in roles that work adjacent to software engineers. You don’t need to know any programming languages to understand this book.
Why read a book? The docs are free!
This is just my personal preference, but I like being spoon-fed information by someone who has already organized their thinking on a topic. I didn’t know what docs to read, or in what order, and I wanted some understanding of the concepts before I tried to do anything myself.
Now I feel ready to dive into the docs and tools.
PS: If you buy the textbook, you also get access to ebook versions for free
I’m kind of a “dead tree” book person myself (they don’t compete for screen space, and I spend enough time looking at screens as it is), but the ebook version of Grokking Continuous Delivery was a pleasant surprise – there’s a nice table of contents on the left, it’s searchable, and the pics are all in color.
The ebook came in handy for deciphering the one error I found in the book – on page 204, the “Top Dog Maps” architecture diagram overlaps some of the text.
And that’s it – thanks for reading! And if you enjoyed this book (or want to recommend a similarly awesome one) please leave a comment!