âTis the season that one of my favorite blog posts gets pulled out and put in rotation, much like âWhite Christmasâ on the radio station. Iâm speaking, of course, of âFriday Deploy Freezes are Exactly Like Murdering Puppiesâ (old link on WP).
This feels like as good a time as any to note that I am not as much of an extremist as people seem to think I am when it comes to Friday deploys, or deploy freezes in general.
(Sometimes I wonder why people think Iâm such an extremist, and then I remember that I did write a post about murdering puppies. Ok, ok. Point taken.)
Take this recent thread from LinkedIn, where Michael Davis posted an endorsement of my Puppies article along with his own thoughts on holiday code freezes, followed by a number of smart, thoughtful comments on why this isnât actually attainable for everyone. Payam Azadi talks about an âicingâ and âdefrostingâ period where you ease into and out of deploy freezes (never heard of this, I like it!), and a few other highly knowledgeable folks chime in with their own war stories and cautionary tales.
Itâs a great thread, with lots of great points. I recommend reading it. I agree with all of them!!
If you canât move swiftly with confidence, you need workarounds
For the record, I do not believe that everyone should get rid of deploy freezes, on Fridays or otherwise.
If you do not have the ability to move swiftly with confidence, which in practice means âyou can generally find problems in your new code before your customers doâ, which generally comes down to the quality and usability of your observability tooling, and your ability to explore high cardinality dimensions in real time (which most teams do not have), then deploy freezes before a holiday or a big event, or hell, even weekends, are probably the sensible thing to do.
If you canât do the ârightâ thing, you find a workaround. This is what we do, as engineers and operators.

Deploy freezes are a hack, not a virtue
Look, you know your systems better than I do. If you say you need to freeze deploys, I believe you.
Honestly, I feel like Iâve always been fairly pragmatic about this. The one thing that does get my knickers in a twist is when people adopt a holier-than-thou posture towards their Friday deploy freezes. Like theyâre doing it because they Care About People and itâs the Right Thing To Do and some sort of grand moral gesture. Dude, itâs a fucking hack. Just admit it.
Itâs the best you can do with the hand youâve been dealt, and thereâs no shame in that! That is ALL Iâm saying. Donât pat yourself on the back, act a little sheepish, and I am so with you.

I think we can have nice things
I think thereâs a lot of wisdom in saying âhey, itâs the holidays, this is not the time to be rushing new shit out the door absent some specific forcing function, alright?â
My favorite time of year to be at work (back when I worked in an office) was always the holidays. It was so quiet and peaceful, the place was empty, my calendar was clear, and I could switch gears and work on completely different things, out of the critical line of fire. I feel like I often peaked creatively during those last few weeks of the year.
I believe we can have the best of both worlds: a yearly period of peace and stability, with relatively low change rate, and we can evade the high stakes peril of locks and freezes and terrifying January recoveries.
How? Two things.

Donât freeze deploys. Freeze merges.
To a developer, ideally, the act of merging their changes back to main and those changes being deployed to production should feel like one singular atomic action, the faster the better, the less variance the better. You merge, it goes right out. You donât want it to go out, you better not merge.
The worst of both worlds is when you let devs keep merging diffs, checking items off their todo lists, closing out tasks, for days or weeks. All these changes build up like a snowdrift over a pile of grenades. You arenât going to find the grenades til you plow into the snowdrift on January 5th, and then youâll find them with your face. Congrats!
If you want to freeze deploys, freeze merges. Let people work on other things. I assure you, there is plenty of other valuable work to be done.

Donât freeze deploys unless your goal is to test deploy freezes
The second thing is a corollary. Donât actually freeze deploys, unless your SREs and on call folks are bored and sitting around together, going âwouldnât this be a great opportunity to test for memory leaks and other systemic issues that we donât know about due to the frequency and regularity of our deploys?â
If thatâs you, godspeed! Park that deploy engine and sit on the hood, letâs see what happens!
People always remember the outages and instability that we trigger with our actions. We tend to forget about the outages and instability we trigger with our inaction. But if youâre used to deploying every day, or many times a day: first, good for you. Second, I bet you a bottle of whiskey that somethingâs gonna break if you go for two weeks without deploying.
I bet you the good shit. Top shelf. đĽ
This one is so easy to mitigate, too. Just run the deploy process every day or two, but donât ship new code out.
Alright. Time for me to go fly to my sisterâs house. Happy holidays everyone! May your pagers be silent and your bellies be full, and may no one in your family or friend group mention politics this year!
đđđđđ§Ąâ¤ď¸đ
charity
P.S. The title is hyperbole! I was frustrated! I felt like people were intentionally misrepresenting my point and my beliefs, so I leaned into it. Please remember that I grew up on a farm and we ended up eating most of our animals. Possibly I am still adjusting to civilized life. Also, I have two cats and I love them very much and have not eaten either of them yet.
A few other things Iâve written on the topic:



We call ours âcode slushiesâ. Itâs not frozen, but your risk and urgency bar gets higher and higher the closer to the 24th you get. Can it wait? Can you do something else that last week? Helps itâs mid summer and no one wants to be paged from the beach.
Previous job even got a literal slushy machine in. That was⌠diabetic coma inducing.