Learn the Different Types of Software Releases

“In a world where downtime is the ultimate villain… only a handful of clever release strategies can save the day.”

Welcome fellow Technical Program traveler, to the curious, caffeine-fueled world of software release types. If you thought “releasing code” just meant someone hitting a giant red “Deploy” button and then sprinting for cover… well, you’re not wrong. But there’s a lot more science, art, and panicked Slack messages involved. And as a Technical Program Manager, knowing what is out there, what is possible, what should be happening is important.

I will provide a quick bird’s eye view of software release strategies, from cautious canaries to color-coded duels of death.

Canary Releases

If the canary sings, all is well. If the canary keels over, maybe delay the global rollout.” – Ancient DevOps proverb (probably)

A canary release is the software equivalent of dipping your toe into the pool before cannonballing in - testing the waters. You release your new version to a tiny subset of users first (1–5%) and watch closely for any major failures, slowdowns, or users suddenly screaming into the void (why its crucial to setup your alerts, observations and monitoring well). It provides the benefit of:

• Fast feedback;
• Limited blast radius if things go sideways; and
• Lets you test real-world scenarios without risking the whole ecosystem.

Blue-Green Deployments

All warfare is based on deception. All deployments are based on double environments. – Sun Tzu.

In a blue-green deployment, you maintain two identical production environments, a blue environment which is your current live site, and a green one with the new version you want to deploy.

You prepare your green environment until it’s ready, and then flip the switch (usually a DNS or load balancer) and traffic flows to the Green. If a major problem occurs, you flip back to Blue rapidly.

The benefits of this deployment strategy is that it:

• Presents Near-zero downtime; and
• Straightforward rollback.

Rolling Releases

“Slow and steady wins the race, and sometimes deploys the app.”

A rolling release gradually updates your servers one slice at a time. Instead of a one-shot monolithic update, you update a few servers incrementally, observe, monitor, and update some more. It provides the added benefits of:

• Reducing load spikes;
• Provides greater safety for large distributed systems; and
• Allows real-time monitoring of smaller components.

Kubernetes (the grandmaster of container orchestration) uses rolling updates by default.

Feature Flags (Dark Launches)

“Why deploy slower when you can ship it turned off?” – Devs everywhere

Feature flags let you ship code into production but keeps features disabled or hidden. The features can be turned on enabled easily without re-deploying. It allows you to:

• Test features with specific users; and
• Instant rollback without redeploying.

Companies like Etsy and LinkedIn heavily use feature flags to manage risk while moving fast.

Which do you Choose?

Choosing your release strategy is about mitigating risk, maximizing success (and minimizing forehead-shaped dents in your desk). Each approach has its strengths. Sometimes it makes sense to even combine strategies, such as Feature Flags + Canary + A/B Testing. A few things to remember:

• Always monitor like your job depends on it (because it does).
• Always have a rollback plan (because fate is cruel).
• And always, always thank your SREs and DevOps friends. (They know how to hide bodies… err, bugs.)