One of the most important questions asked by a new web developer is….what the hell this is this “staging” thing ?! The answer is simple.
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).
“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:
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.
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?
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:
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