continuous deployment - Coffee on the Keyboard

Sign in Subscribe

continuous deployment

A collection of 11 posts

Photo of a path to an ocean beach with a temporary barrier that says "beach closed"

Introducing API Boundaries to Prepare for Bigger Changes

Alternatively: API Boundaries for Fun and Profit I routinely misquote Kent Beck, who said "for each desired change, make the change easy (warning: this may be hard), then make the easy change." He said this on Twitter (RIP) so I won't be linking to it, but at least for now

Photo of colorful papel picado banners strung between two buildings with a partly cloudy sky behind.

continuous deployment

When to use Feature Flags: Extra-Ordinary Unconfidence

Feature flags are a sine qua non for effective Continuous Deployment (CD)—and yet, they aren't always necessary. Nearly every sprint I've observed for the past 10 years has included the question "should this be feature-flagged?" at least once. Such a common question deserves some framework for answering. Start with

A zoomed out photo of a dictionary open to a random page. The text is mostly blurred.

Changing the Meaning: Breaking Semantic Changes

The subtlest kind of breaking change is the kind that doesn't affect a value's type but instead affects what that value means. These changes can be hard to notice when you're making them, and even harder to debug when they happen. They can lead to downstream effects like broken reports—

A graph in the positive quadrant showing y=x, y=x^p where p>1, and y=x^p where p<1.

Three Models of Value

In product development, we often think of "value" in large, discrete units: the value of project A vs project B; the value of a feature; the value of a refactor or architecture change. When we're deploying continuously, we have an opportunity to replace this mental model with a more continuous

A close up of wires plugged into a sound board.

Building Extensibility into APIs from the Start

Making the right design decisions early in a project can have a huge impact on the ability to safely improve and evolve it over time.

A photo of an older, wooden sliding garage door made of four panels, with windows near the top.

continuous deployment

Sliding Windows of Compatibility

Writing software professionally means constantly changing, evolving, and migrating applications. All-new "greenfield" projects are a rare treat, but not the norm. Constant change means we have to be comfortable making big changes applications that are running in production environments, usually with customers using them, and do it safely, without downtime

Photograph of a red carpet partly rolled out on grass.

Caller-controlled Rollouts

Slightly warm take warning: not everything needs to be feature-flagged. New APIs or API endpoints, for example, that have no callers yet, don't benefit from the ability to toggle them off. If nothing is executing this code, then there's no behavior to disable. Let's say we have an API for

The Creative Power of Zero

Yesterday, I wrote about how a three-legged deploy process enables migrations in continuous deployment (CD). Today I want to talk about the creativity that hides in the gap between "a little" and "zero." One way to look for opportunities—I think attributable to Marty Cagan—to innovate is to take

continuous deployment

Zero Downtime and the Art of Continuous Deployment

I've been thinking a lot about the relationship between availability and continuous deployment (when I say "CD," I usually mean "deployment," all the way to production). One of the primary concerns people raise about CD is the perceived risk to availability or uptime. But there are patterns we can adopt

continuous deployment

Acronyms you should know: MTTD and MTTR

If you’re a SUMO [https://support.mozilla.com/] contributor, there are two acronyms you will start to hear more often from us developers: MTTD andMTTR. They mean “mean time to detect” and “mean time to resolve,” respectively, and they refer to how long it takes to detect an issue

continuous deployment

A brief SumoDev update

A little while ago [https://coffeeonthekeyboard.com/sumo-in-q2-563/], I said that I thought we got a B in Q1, but we could move up to an A with a little more work. (This is my favorite grading system: everyone starts at 0 and works up.) Well, we landed two things: