The 7 Stages of Grief When Deploying to Production

Most developers experience the same emotional rollercoaster when pushing code to prod. The index finger hovering as you run through your mental checklist. That held breath as you confirm deployment. The anxious moments as you grab a fresh coffee, knowing these could be your last moments of calm.

Then it starts: Too many phones start ringing. Distant voices rise—first slightly, then panicked. Footsteps walk too fast, getting closer, closer.

Let’s break down each stage—and, more importantly, how to avoid this drama.

Stage 1: "This will be a smooth deployment." (Denial)

This release is mostly (or entirely) your code. You know everything that changed. You tested it extensively. You don’t want a repeat of what happened three releases ago, when… NO! We’re not going to manifest failure today.

This is a small change. We’re just recording the last login time.

Click.

See? That wasn’t too hard.

And off you go to enjoy the rest of your day—planning the next set of tasks, preparing a single-slide PowerPoint (I will NOT call it a slide deck) for a two-hour meeting because management doesn’t like email.

Then, you check support tickets.

• User can’t log in.
• Page is slow to load.
• User can’t log in.
• User can’t…

Wait. No. I’m sure it’s not related to—

Whatever. It’s 5:00. Issue password resets and go home.

Stage 2: "Wait, why is the database empty?" (Anger)

You obviously didn’t wipe the database. (Again.)

But the next morning, there are too many people in your office.

"Funny, you never seem to find this office when there’s cake," you quip, but nobody smiles.

• “The entire system is down!”
• “We’ve been hacked!”
• “It’s probably ransomware!”

We’ve all been there. We all know they’re wrong. Eventually, you find out nobody can log in.

"Wait, I definitely didn’t wipe the database, right? Did I? No way. Unless…"

Casually checking logs while sweat beads form.

Phew. The data is still there.

You open the app and log in just fine.

• “Well, customers can’t log in. You need to fix it NOW. I’ll send you the accounts that have called so far.”

You bite your lip, resisting the urge to tell them to please put it in a ticket.

Turning back to your laptop, you see Windows has chosen this moment to install updates.

Time for coffee.

Stage 3: "Let’s roll it back—oh wait, rollback is broken." (Bargaining)

When you return to your desk, coffee in hand, you log back into the app... You log back into... You log...

No biggie, we planned for this. Well, we talked about planning for this.

I’ll just roll back the update.

Let me find where I saved the zipped copy of the production folder before deploying. (Side note: This was actually the rollback strategy at a company I worked for.)

Deploy it back.

Done.

Now I log back in, and—

Nope.

Where are the images? Why does the page look like trash?

Ah, the CSS files are missing too. Great.

Fine. Password reset. Log in.

YES! I’m a genius.

Now we just need to:

• Issue password resets for every locked-out user.
• Find those images and CSS files.
• Pray.

Stage 4: "This is fine." (Depression)

At least yesterday’s release stored the Last Login Date in the user table.

But they’re all NULL.

Even mine.

Whatever. I’ll get around to that later.

For now, I’ll write a quick script to issue password resets (yes, it’s manual; it’s a legacy system).

While that runs, I’ll drop in the CSS and images from my local instance.

At this point, I don’t even care why it broke. Just fix it so people stop coming into this office.

You stare at the little progress indicator in your script, contemplating a career change.

Goat farming sounds peaceful.

Or raising geese.

Stage 5: "We fixed it!" (Acceptance)

With a heavy heart (and a deep hope nobody asks questions), I close the ticket and send an email:

"If you’re still experiencing issues, a password reset should resolve them."

I, of course, blame it on a legacy module of the legacy system, hoping it supports my call for a complete rewrite.

Stage 6: "We missed something, didn’t we?" (Fear)

You know you missed something.

You grab the PR, git reset --hard to the previous commit, and begin reimplementing.

Thumbtacks stuck to Ctrl to prevent you from copying and pasting.

Everything seems straightforward. The changes look identical to the botched PR.

So what happened?

Stage 7: "It wasn’t my fault." (Relief)

It must be a legacy issue.

For real this time. Right?

You replicate the changes, deploy to the test environment. It doesn’t break.

Clone the production server. Still doesn’t break.

Big sigh of relief.

And now, the last login timestamp is populating correctly.

Must have been:

• A weird build process issue.
• Corrupt files when zipping.
• Memory corruption?
• Solar flares?

Bonus Stage 8: “It actually was my fault, but I’ll deny it.” (Postmortem)

You finally review the merge.

And your spidey sense tingles. (Or is it your anxiety disorder?)

Why didn’t the last login save?

UserData[24].SetValue(Utils.TimestampUTC);

(Yes, it’s an array of values. Not even an Enum. Did I mention it’s a legacy system?)

And then it hits you.

UserData[24]. That seems low. Wasn’t the new column index 38 or 39?

Step through the debugger.

Why is there a hashed value there?

Ah.

A classic "off by 14" error.

You briefly wonder if a proper CI/CD pipeline could have saved you.

Yes. Absolutely.

But where’s the fun in that?

Lessons Learned (or “What I Should Have Googled Earlier”)