Programmings big dirty secret is that everyone has, at some point in their career, broken something big.

There are a million reasons why things go wrong, and not all are completely avoidable.

But having a good setup for testing newcodecan at least mitigate some of the worst errors.

Yes, staging can be a pain — but here’s why you shouldn’t skip it

Traditionally, deploying new code to a website or utility follows three steps.

First, an engineer writes code and tests it on their local machine i.e.

Now this sounds like a pretty good setup right?

But could this be hurting you more than helping?

Facebook does it… 1% of users in Hungary and, if that works, rolls out updates to a wider audience.

But not every company has billions of users like Facebook.

For most companies, there are no life and death dependencies on their product.

Then again, this might not be the most user-friendly approach.

Rather than removing accountability, it shifts it to the wider team.

Let me make an analogy to a restaurant.

Or all of it.

The same goes for staging.

You dont necessarily need the same hardware capacity to test out code for production.

As long as you take into account the relative resources youre using, it should deliver useful results.

It worked on my machine

Staging your code isnt just about making sure it works during production.

Staging is also about getting other stakeholders on board.

That might be true, but it also helps break down silos amongst different product teams.

Its basically like running two parallel but identical restaurants.

This can be quite tedious.

Building this from scratch might seem like a mighty task.

So if youre thinking about ditching staging environments, think again.

Also tagged with