Yes, staging can be tricky, but here’s why you shouldn’t skip it

The big dirty secret of programming is that everyone has broken something big at some point in their career.

Big like, wiping the entire production database on their first day of workkilling the live application while multiple sellers show it to customersor knock down half the internet by passing on wrong data.

oops.

There are a million reasons why things go wrong, and not all of them can be completely avoided. But having a good setup for testing new code can at least reduce some of the worst errors.

Traditionally, implementing new code on a website or application follows three steps. First, an engineer writes code and tests it on his local computer, his own computer.

If that works, that code is deployed in a so-called staging environment, which is pretty close to the real thing. In the staging environment, new features or updates can be tested using real or anonymized data as a final step before finally pushing the code to production.

It’s a bit more complex than that, though, with staging environments being split into multiple branches or forks allowing testing of several functions at the same time. These forks are then reassembled into the staging environment code and sent to production as a batch once they have all been proven.

This sounds like a pretty good setup, right? A bit like how new planes are first tested many times on the ground, then flown without passengers and finally given the green light to carry people.

Nevertheless, many engineers have recently stopped using staging environments altogether, arguing that it’s better, faster, and cheaper to skip that stage and just roll out new updates and features right away. But could this hurt you more than help?

Let’s take a closer look at why some engineers omit staging environments and why these arguments might not make sense.

Facebook does it…

Many point to Facebook, which is known for not using a staging environment, instead pushing changes to a small (but still large) subset of users – say 1% of users in Hungary – and, if that works, updates to a wider audience. But not every company has billions of users like Facebook.

Of course, depending on one’s tolerance for downtime and running hotfixes, an argument can be made to simply roll out new releases in the wild and see what happens. For most companies, there are no life and death dependencies on their product. And simply allowing a website or app to stop responding no matter how long it takes to revert changes and check what caused the failure may be an option.

On the downside, this may not be the most user-friendly approach. There may also be agreements in place with customers that limit the downtime threshold before penalties are imposed on the service provider (you).

Instead of taking responsibility away, it shifts it to the broader team.

It’s important to make sure that any updates or changes that are intended to benefit the customer – and may even be a direct request from them – actually work as intended and that your account managers don’t have to beg for forgiveness.

Staging environments are too expensive

Depending on the size of your website or application, keeping extra servers for staging could result in a grieving CFO paying double AWS bills.

Let me make an analogy with a restaurant. Yes, keeping your kitchen fully stocked and staffed to try out new menu items for a restaurant will eat into your bottom line. Or everything.

But a new recipe can also be prepared and tested at home, on a normal stove, with smaller amounts of ingredients.

The same goes for staging. You don’t necessarily need the same hardware capability to test code for production. As long as you take into account the relative resources you use, it should yield useful results. And if you make sure to stage mirror production instead of your home setup, you should find out soon enough if you’re missing ingredients.

IONOS’ Deploy Now feature takes care of that, for example, by launching and managing feature branches in the staging phase, without breaking the bank.

It worked on my machine

Getting your code ready isn’t just about making sure it works during production. Staging is also about getting other stakeholders on board.

Anti-staging proponents argue that having a staging environment dilutes accountability because developers throw their code over the fence at the people who control it.

That may be true, but it also helps break down silos between different product teams.

A staging environment allows designers to test how things look, it allows quality assurance engineers (QA) to test the new code across platforms, product managers can track changes, and customers can get a feel for a new feature before it is released. goes live.

It’s basically like running two parallel but identical restaurants.

Instead of taking responsibility away, it shifts it to the wider team, which in turn encourages more involvement and involvement with the product.

Staging leads to large queues

If you’re a larger organization with many teams working on different parts of an app, having a single staging environment can lead to longer approval processes. they have to go back and fix elements of a previous feature after starting a new project.

This can be quite cumbersome.

Ideally, you would want staging to automatically have multiple feature branches with associated staging environments that allow code to be tested immediately and pushed live after passing all checks.

Again, it can be a chore to manage, but IONOS’ Deploy Now feature can pretty much do it for you. In principle, that should mean that you can deploy continuously, without building up large queues — or losing productivity due to job changes.

Staging is not equal to production

Another reason why some people hate staging is that it takes a lot of work to keep the staging environment in a state of copy with production.

This applies not only to all dependencies, but also to the data that is used during production but cannot be used during staging because it contains things like passwords, personal identities, or credit card information.

This means that you need to maintain a dummy dataset and the schema of that data needs to match the information you have in the staging and production phases. Developers also need similar dummy or test data for local development (or the assessment) so that it can also be used for staging.

It’s basically like running two parallel but identical restaurants.

Building this from scratch may seem like a daunting task. Then again, if you start with a good staging environment and make sure it’s regularly updated to reflect production, it just takes a little extra time to keep it up.

And if you keep that habit up, your company can keep your engineers productive and, more importantly, keep your customers happy.

So if you’re thinking about ditching staging environments, think again. Rather than being a cumbersome process, maintaining this product development stage will help smooth out the customer experience and allow you to engage the wider business, without breaking the bank.