Staging strategies (beta, pre-stage, QA)

The answer is simple: in your day-to-day work you want to be able to show a client or someone else the results of your labor, receive feedback, and not push buggy code. Staging environments are a perfect way to achieve this.

You can always show clients a screenshot, a mockup, or post a video with new features, but the best results will come when you give a place for someone else to click around, browse and spot something which they can interact with.

Staging is the first stage in continuous integration cycle, following a development stage, where changes you’ve made are visible to someone else (at least a non-tech person, because another dev might have pulled your code already).

Why bother with staging? Why not just push directly to production?

“Hey Client! Feature X is ready! Just go to ‘www.xyz.com/newfeature’ and click on… oh, wait a second, don’t check it yet, I have to do Y because Z on production is different than Z on my machine. sorry! :sadpanda:”

To avoid situations like this, staging is a necessary part of the development lifecycle. Staging essentially makes clients and users happy and allows you to not push crappy code. The first thing to do is ask yourself, “What can be different from my dev machine versus production?”

Here are just a few examples:

• Your OS is different
• There is no lib XXX installed on the production server
• The production server IP isn’t whitelisted for YYY service

There are a lot of different things to consider, and all of them might go wrong. In order to be prepared for them, it is extremely good practice to have some kind of staging environment where you can test things out.

Staging in a continuous integration cycle

The staging phase is placed between your dev machine and production server. When your tests have passed new version of staging is build and you can ask others for feedback about introduced changes. Why waiting for tests?

• when your code is telling you that something is wrong, you should fix it before showing it to someone else, simple as that.
• when you have feedback based on staging experience (this feature needs some tuning / I can’t access API from the site) you should be safe to push things into production.

Different staging strategies

The development stage isn’t staging, or at least it shouldn’t be regarded as one. Dev is a place which changes all the time and it often presents work-in-progress and isn’t a reliable source to know whether or not a brand new feature is ready to be brought to production.

Staging can be super simple - just one stage following development and one stage before production. However, it is often the case that the situation is more complex. You can look at staging as an entire cycle that can contain any of the following:

Staging/QA (C-C-C-Combo)

• you have your new feature and some dummy data (probably lots of john and jane doe guys)
• deploy process is checked - staging configuration is almost identical to the one on production
• it provides a fast way to receive feedback
• limited for devs and client

stage + beta

Stage:

• dummy data on stage
• feedback might be provided after not-so-much-detailed inspection of feature
• APIs and product work in development mode (more detailed logs, non-minified assets) * helpful for dev
• mostly used by devs (there is interesting info for them) or by bored QA team

Beta:

• database is shared with production, or is a copy of production data (be careful and strip all the critical data!)
• things should be tested thoroughly, you have a real production data here, so you will be able to catch all the errors caused by migrations and changes which regular users will be exposed to. did you have issues with user name containing some non-english characters? there will be spotted here right away.
• most of end-user test are done here
• we may allow access for some production users to the site in order to get the best feedback (as long as the feedback is more detailed than: “webpage is down”)
• some of APIs might be enabled only for this environment

Main goal of having a staging environment(s)

Your production should be in the best possible condition! It’s better to sacrifice some time and resources and test it in few aspects besides the actual feature testing (e.g. machine setup, 3rd party plugin configuration, end point accesses, etc.).

If you have stage and beta environments, consider them as stage = preview and beta = I think it’s ready. even if it looks complicated, dev team, QA team, and client (feature founder) should be able to understand quickly which part of the staging phase should receive the most attention.

You can join the discussion at reddit.com/r/webdev