Engine room Beat Wuffli - CTO February 26, 2026

Champagne vs. vodka releases

TL;DR

There are two types of releases: champagne releases, where everything goes smoothly and vodka releases where nothing goes right. Strong CI/CD and testing infrastructure help and are well worth the investment. Champagne releases should be the norm and the occasional vodka release survivable.

What can go wrong in a release

All happy releases[1] are alike; every unhappy release is unhappy in its own way.[2] The reality of software releases is that there are near infinite ways in which things can (and do) go wrong. When they do, you're in vodka territory.

The challenges multiply with a team working on a project. It is worsened by:

  • Complex deployment environment e.g. multiple instances and microservice architecture
  • Dependent systems and data e.g. caching, databases that need migration, blockchain data, message queues, etc.
  • Access restrictions due to PID or security requirements
  • Uptime requirements and business pressure adding urgency and stress

Most of this is not inevitable. Some concrete actions that can be taken to mitigate the risk of a vodka release:

  • Proper release planning and ensuring everyone who needs to be is on deck
  • Clarifying dependencies in advance to reduce surprises
  • Representative test / staging environment as well as a decent automated testing suite to be able to easily verify the inevitable last-minute changes and fixes
  • Keeping the scope of each release as small as possible[3]
  • Automated deployment pipelines and configuration as code

Even with all that, a happy release is not guaranteed. Which is perhaps just one more good reason to NEVER RELEASE ON FRIDAYS!

Vodka vs. champagne releases

Having looked at what can go wrong, here's the profile of a champagne release:

  • Over in minutes, not hours
  • Occurs during normal waking hours
  • No urgent bug fixes, follow-ups, clenched teeth
  • No frantic attempts to get hold of that person you forgot to involve
  • No heroics were required; no post-mortems need scheduling
  • No-one is stressed, everyone has a smile on their face, people are congratulated

... basically, everything is good and people are ready to open a bottle of champagne. All happy releases are alike. Champagne releases must be the objective.

Vodka releases are the other side of the coin. They will occur, often when you least expect them and must be endured. Maybe some of my best memories of the time at Sygnum are from the rough releases and finally figuring it out together with the team. Succeeding despite the challenges can be a good experience, like surviving an adventure. You have a story to tell. The team grows closer from shared suffering. But the overarching objective of a healthy development process must be to make this unnecessary.

In a champagne release, the process works.

In a vodka release, the team scrambles to prevent disaster.

Origins

I'm not sure who came up with this. For the longest time, I thought this was an industry term, but it might have originated at Sygnum during the time I was there.[4] I vaguely remember a particularly challenging release where a bottle of vodka was involved. Not during the release itself - mind you - we're not insane and had no desire to burn more midnight oil due to some sloppy mistake. It was already the kind of late where you have to get up occasionally and wave at the motion sensors to keep the lights on. When all was finally done and live, that bottle of vodka was there, and we all signed our names on it and then proceeded to reduce it.[5]

Implications

Within reason, I would argue that putting time into CI/CD, clearly delineated architecture, and testing infrastructure is an excellent investment. As with many things, it is better to pay up front, rather than having to clean up later, on someone else's schedule and with a mind clouded by adrenaline.

An underappreciated aspect of this is that time from push to deployment makes a huge difference. In the worst sort of releases, when it is not immediately obvious what went wrong in the first place, there is a gulf between being able to try a fix in 3 versus 30 minutes. It's the difference between 2 attempts per hour to get it right and 20.

At TalSource, I've put these lessons into practice.[6] We can deploy a new version in minutes. We have an extensive set of well-maintained e2e tests that allow us to catch regressions. There's an up-to-date pre-release checklist.

"What's that, you don't really like champagne," you say? Well even with all that, occasionally we still have a vodka release every now and then. Murphy sees to that. And then there's still a chance to break out the vodka.

Footnotes

  1. When I'm talking about releases, I refer to pushing code to production for clients and internal users.
  2. Shall we christen this the Anna Karenina principle of releases?
  3. Recently, my own instincts in this regard frequently come into conflict with an AI empowered development process that inevitably seems to bloat releases. I'm still looking for a good balance.
  4. I realized this when I was asking LLMs to review another blog post draft and it kept pointing out that vodka release was likely an error.
  5. I still have that empty bottle somewhere. I have several deal tombstones from my 3 years in investment banking, that empty bottle fits neatly into that collection of trophies.
  6. This is easy in some ways, because I have decision authority, but hard in others, because as a start-up our resources are limited.