Book review: Grokking Continuous Delivery by Christie Wilson

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.

See “Grokking Continuous Delivery” on

A sample page from early in the book.

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”).

What’s inside

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.

Another peek inside the book.

What I’ve learned

A lot.

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.

Book is available as pdf, epub, kindle, and liveBook
Here’s what the liveBook version looks like in Chrome – the table of contents down the left side is particularly pleasant.

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.

On the left: the diagram overlaps a line of text in the book. On the right: the publisher has corrected the problem in the ebook and future print editions will contain the correction.

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!

See “Grokking Continuous Delivery” on

AngularJS: Chaining multiple functions in one ng-click

Today I learned… a little¬†trick for performing multiple functions in a single ng-click. Just separate them with a semicolon (;) like so:

<button ng-click="selectTab(); $parent.someVar = true">Button Text</button>

This comes with a¬†noticeable caveat: it complicates your template code. Generally, it’s considered¬†good practice to minimize the amount of logic that happens in an html template.¬†If you need to do many things on a¬†single ng-click,¬†you should consider writing (or refactoring) a method in your controller to handle them with just one method call.

Nonetheless, this¬†odd bit of Angular syntax can be useful, even if it never makes it to production.¬†In my case,¬†I needed to modify $parent.someVar on click, which was (at the time) outside of the button’s controller.¬†Ultimately, this code was refactored so that someVar could be modified from within selectTab(), but¬†when I needed¬†a quick and dirty implementation to demo something, chaining functions on a¬†single¬†ng-click got the job done.

Wait, what does $parent.someVar do? What is $parent?

$parent allows code within a child controller to access something contained within the parent scope.

In my project I had multiple scopes.

<div ng-controller="PageCtrl">
   <div ng-controller="SectionCtrl">
      <button ng-click="selectTab()">Button Text</button>

someVar was contained within PageCtrl (the parent scope), but I needed to manipulate it from a button inside SectionCtrl (the child scope). Using¬†$parent, the SectionCtrl code could “look up” into the parent and find someVar. This Stack Overflow Q&A explains $parent with more examples.

Read this: Airbnb’s Excellent JavaScript style guide

Today I learned… that¬†Airbnb¬†has a fantastic JavaScript “style guide” available for free on github. The guide is¬†light on long-winded explanations and¬†big on DO and DON’T examples. Check it out, it’s a 15 min read at most.

Here are just a few of the things I learned from it:

Declaring multiple variables

A long list of variable declarations should be done with the unassigned variables last, and all declarations can share one use of var.

// multiple var declarations like so:
var items = getItems(),
    daytime = true,

I’m definitely guilty of var var var var var… but¬†I’m not sure how I feel about this particular style. I like the clarity and editability of beginning each line with var, but for declaring lots of like items, I can see the usefulness of this style.

Shortcuts for the win

Instead of writing¬†“if this thing is greater than zero”, you can just write “if this thing”.

Here’s an example:

// bad
if (cars.length > 0) {
  // ... code here

// good
if (cars.length) {
  // ... code here

Easy enough.

Comment with good style

Oops, I’ve definitely been getting this one wrong. Comments belong on their own line, not off to the right of the line the¬†comment explains.

// bad
var active = true;  // is current tab

// good
// is current tab
var active = true;

Guilty. I’ll quit doing this, as tempting as it is for the sake of¬†shorter files…

Saving a reference to “this”

Oops,¬†here’s another mea culpa. I’ve been saving reference to “this” as “self”, but the style guide suggests _this as a better alternative.

I’m inclined to agree – I found “self” confusing the first time I encountered it, and its relation to “this” wasn’t immediately apparent.

// bad
function() {
  var self = this;
  return function() {

// bad
function() {
  var that = this;
  return function() {

// good
function() {
  var _this = this;
  return function() {

Those are just a handful of the discoveries I made while exploring this guide.

Be sure to check it out yourself and¬†see¬†what you could be doing better, and don’t miss the giant list of resources at the bottom of the page!