For our software development process we used to set up 3 environments : integration , QA and master.

Recently it was decided to add a new staging environment that shall mirror the production environment for further testing. Our production environment uses kubernetes, SSL, Load balancing, and others components and configuration elements. Do I need to use all of them in the configuration of the staging environment as well?

Also, what other configuration differences should we keep in mind when setting up a staging vs production environments?

(I apologize for the question, but I am not experienced in the definition of system landscapes for software development processes).

  • Sharing your research helps everyone. Tell us what you've tried and why it didn't meet your needs. This demonstrates that you've taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask
    – gnat
    Jun 4 '21 at 12:26
  • 2
    Your boss is the only person who can answer these questions being that they have asked you to mirror your production environment - so you need to seek clarity on exactly what they want; understand from them how closely they wish it to resemble production, and whether they wish to test the things you've mentioned here. Questions of "Do I need to..?" ultimately boil down to your/their requirements and how much they are willing to spend. Jun 4 '21 at 12:50
  • This question was closed due to lack of focus. But it seems that there were questions related to staging environments, that had much less focus and were considered as acceptable (e.g. softwareengineering.stackexchange.com/q/117945/209774). This one gives at least the goal of this environment, and asks how far it should go in the mirroring. Even if we do not know what the boss asked, and some specifics are not known, there are sufficient objective arguments that can be provided, that could help other people who have similar tasks. I therefore propose to reopen it.
    – Christophe
    Jun 6 '21 at 0:25
  • (btw it's not the only example since there is for example also this: softwareengineering.stackexchange.com/q/358223/209774 and a couple of others in the list softwareengineering.stackexchange.com/… )
    – Christophe
    Jun 6 '21 at 0:30

If your staging system is meant as pre-production environment, to test it in almost real situation:

  • your staging environment should technically seen be the replica of the production system, including for the versioning. (i.e what the sense to test everything carefully, just to find out that due to an older OS version it fails on production)
  • it could also be a downscaled version (i. e. instead of 30 application servers in production, you run only two of them), but all the components must be there (i.e. load balancing, reverse proxy, etc.)
  • since it is almost production, authorization and security should be at the same level - no shortcut here (how many time did I see cooler authorizations settings “to test more easily” just to find out that production users could not do what they needed or enjoy the promised comfort because of different security).
  • Since it’s almost production, you must be extremely careful on its relations to the external world: interfaces should be with other staging systems, and most of all beware email or SMS notifications: those of the staging environment might look as real as those on production, and you don’t want your colleagues to ring the alarm bell because of mysterious transactions that never happened for real: watermark the output, or use staging relays that make sure that outgoing messages are marked as “test” or not even sent.

But there is no authoritative definition of a staging system. So it can mean different things to different people. Some use a staging environment just for functional and user (acceptance) tests. This is simpler and less expensive, but it’s a different purpose.

Conclusion: ask your boss to clarify the purpose of the staging system and the precise requirements.


I believe the question answers itself.

If you are asked to "mirror" the production environment in your new staging environment, then that is what you should do. If you want your staging environment to mirror your production environment, you should use all of the same components in the same configuration. There should be as few differences as possible, preferably no differences, between your staging and production environments if you want to truly mirror the production environment.

Using infrastructure-as-code and scripts to configure environments can help ensure that your staging and production environments are close in configuration and any differences would be obvious by diffing the code.

I'd even argue that your staging environment should have the same scale of data (although sanitized and anomymized) as your production environment, but this may vary depending on exactly what you are using the environment for.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.