I’ve been deploying software for 47 years and I’ve never once deployed “continuously.” You know why? Because the best things in life come in single, catastrophic events.

Earthquakes. Supernovas. My 2017 Christmas deploy. All unforgettable. All transformational. All completely unrepeatable.

Continuous Delivery is the participation trophy of deployment strategies. Real engineers ship big. They ship everything. They ship it on a Wednesday after 9 PM when the monitoring team has gone to dinner.

The Philosophy of Big Bang

The premise is simple: accumulate 6–18 months of changes, bundle them into a single file named final_v2_FINAL_approved_v3_USE_THIS_ONE.tar.gz, and push it to production while everyone is watching a football game.

This is not recklessness. This is drama engineering.

Strategy Changes per Deploy Excitement Level Job Security
Continuous Deployment 1–5 lines Boring Low (anyone could do this)
Weekly Releases ~500 lines Mild anxiety Medium
Monthly Releases ~5,000 lines Sweating High
Quarterly Big Bang 200,000+ lines Full incident response Guaranteed
Annual Legendary Release 1,000,000+ lines Company-wide outage Mythological

Why Incremental Deploys Are for Cowards

“Feature flags,” they say. “Canary deployments,” they cry. “Blue-green infrastructure,” they beg.

You know what a canary in a coal mine is? A warning that you should stop mining. But we’re not stopping. We’re mining harder. All the canaries die at once in a Big Bang release. That’s called efficiency.

# The correct deployment pipeline
git log --oneline | wc -l   # Count how many commits since last deploy
# Output: 4,847
# Perfect. Ship it.
git push origin main
# That's the whole pipeline.

“Wally, why hasn’t this service been deployed in 8 months?”
“I’m letting the code mature.”
— Dilbert, every standup

XKCD #1421 - Future Self shows your future self looking back at your decisions. In Big Bang releases, the future-you is a much richer person — in experience, in scar tissue, and in late-night delivery receipts.

The Step-by-Step Guide to Big Bang Releases

Months 1–5: Accumulate Changes
Merge everything to main without testing. Testing is pessimism. If you test, you’re assuming your code is wrong. Have some self-confidence. Your code is probably fine. Probably.

Month 6: Write the Changelog
Just write “Various improvements and bug fixes.” Honestly, you have no idea what’s in there either. Neither does git. It’s a surprise for everyone.

The Week Before: Preparation

  • Tell no one the deploy date
  • Back up nothing (backups are for pessimists)
  • Disable alerts so you can “focus”
  • Book a hotel near the office “just in case”
  • Order 40 energy drinks to be delivered Friday morning

The Deploy Itself
11:47 PM on a Friday. Not because of the deploy on Friday philosophy — this transcends that. This is art. This is performance. This is your magnum opus.

Post-Deploy
Watch the dashboards turn red. This is normal. This is beautiful. This is the moment you realize you are, in fact, alive.

Managing Stakeholders During the Incident

The PHB will call. He always calls. The script:

“We’re doing a phased rollout.”

This is technically true. Phase 1: everything breaks. Phase 2: you fix it at 3 AM. Phase 3: you call it “complete” and declare the outage “expected behavior during the migration window.” Phase 4: you write a postmortem you’ll never finish.

Dogbert’s legal team will be proud of the phrasing.

The Hidden Benefits Nobody Tells You

1. You only have one incident per quarter.
Continuous Deployment teams have incidents continuously. Who sounds more stable now? Our incident count is technically 75% lower.

2. It becomes a company holiday.
The whole org clears their calendar. People update their resumes. Someone brings donuts. Community forms around shared trauma. This is called culture.

3. It builds cross-functional skills.
Your big bang release will force you to learn: DNS troubleshooting, database recovery, OS-level debugging, hostage negotiation with the DBA team, grief counseling, and how to order pizza for 30 engineers at midnight.

4. Natural selection for your codebase.
Only the strongest features survive a big bang release. The weak ones die in production, as nature intended. This is Darwinian software development. XKCD #1667 agrees that aliveness is emergent.

5. It creates legendary engineers.
Nobody becomes a legend by deploying 3 lines of CSS every Tuesday. Legends are forged in the fires of a 14-hour incident bridge. Mordac, the Preventer of Information Services, would understand.

On Rollbacks

If you deploy something, you commit to it. Marriage. Mortgage. Big Bang release to prod. These are lifelong decisions.

“We need to roll back the deployment.”
“Roll back to what? I deleted the previous version. Progress only moves forward.”
— Mordac, Dilbert (and he had a point)

XKCD #1172 captures this truth: the moment you rely on a rollback, you’ve created a dependency on your past failures. Don’t look back. Never look back.

The Distributed Systems Argument

“But what about microservices? You can’t big-bang deploy 47 microservices!”

First of all, you shouldn’t have 47 microservices. You should have one glorious, all-knowing monolith and deploy it like God intended — in a single bash command, at night, alone, with the confidence of a developer who has never been paged at 3 AM.

(You will be paged at 3 AM.)

Continuous Delivery Is Continuous Disappointment

XKCD #303 - Compiling shows a developer taking a break while code compiles. With Continuous Deployment, you never get that break. The pipeline is always running. You’re always accountable. There’s no escape.

With Big Bang releases, you get 5 months of relative peace followed by one spectacular week of pure adrenaline. It’s interval training for your cortisol levels. It’s healthy. Probably.

The Final Deployment Checklist

Pre-Deploy Checklist:
[ ] Accumulated 6+ months of changes? ✓
[ ] Changelog says "misc fixes and improvements"? ✓
[ ] Hotel booked near the office? ✓
[ ] On-call team notified? ✗  (Surprise is half the fun)
[ ] Rollback plan documented? ✗  (Faith-based deployment)
[ ] Stakeholders warned? ✗  (They wouldn't understand anyway)
[ ] git push origin main --force? ✓
[ ] Prayer offered to the deployment gods? ✓

Go forth and deploy boldly. Or don’t deploy at all for another 6 months. Both are valid strategies. One of them is this article’s entire thesis.

The author’s most successful Big Bang release was in 2003. It is still running in production. Nobody touches it. Nobody knows why it works. The original developer left the company in 2007. Some say the code is sentient. It has never been tested.