Software Environments

Your browser does not support the audio tag.

If you have been involved in any serious software development, you have encountered the need for having multiple environments where the software is running/executing. The software is a very complex thing. There are unlimited variable parameters that could break the train out of the rails - from inside job - bugs in the software, to outside variables - versions of operating systems, run-time programs (.net/java), browsers, edge case user inputs and so on.

There are mostly two cases when developing software - either you are creating an in-house software product - you or the company you work for owns the software you are writing, or you are developing software solutions for clients. Depending on this there may be a few more environments as per best practice standard.

If you are creating a software for clients - a minimal number of environments is 4, for in-house there may be 3. Let's talk about all variations.

Production - this is the mandatory environment on which actual real world users play with the software. On it, if it is implemented properly with implemented all the best practices - no code level logs or error messages will pop up - only translated, user friendly, clear (on what happen, what the software is doing) should be presented. On it also - every action should be logged and recorded - on SQL level (if the application uses relational database), on application level, and on user interface level also. On the front side help services like Facebook pixel and google analytics. On the other layers, the software developers must be very, very good to have implemented all the logging properly. On this environment the best practice recommends minimal to none (better NO) dummy data, especially if the software is about money, health or something else critical. It is not a good practice the saying ("I don't always test my code, but when I do, I do it on production").

Staging - This is Environment that is closest to production in terms of data, configuration, settings, and more. If the project is for client there even may be two staging environments - client staging and developing company staging.

In most cases it has the same data as the production environment but "points" to copy of the production data and so it may also contain dummy data. Sense rise of the data awareness from GDPR, access to data is increasingly tight so in may be the case where - production copy of the data is located only in the client's environment and any not-reproducible by the developer company bugs may need to be resolved with live coding and debugging, without the developing company to acquire real access to the data - only short temporary on the developer's machine.

It is used to reproduce bugs that have appeared on production without adding additional gasoline to the fire, without messing up with either the application itself, nor the real data of the users.

Developer Integration - In many cases the software consist of several modules and platforms - Front-End (Web, Android, iOS, Windows Phone, Desktop with some OS), Back-end, Database layer, that are developed and handled by different people. No Single Person can do it all and fast and with high quality. So This is the environment where all software modules "meet" and resolve any conflicts, bugs, differences of implementation or inconsistencies.

Test Environment - Sometimes the quality assurance team has a separate environment so they could test and verify the software's quality independently from the data that is generated by the programmers in the implementation phase. Many times there is a separate Test Environment for the Automation Tests - scripts that need to be programmed, that verify the business logic of the application.

Local Development - this is the environment on the coder's machine. Sometimes, he doesn't have separate environment and he access the data from the Test or the Integration, less frequently the Stage Environment, but when he does have, he has his hands full of potential to mock, simulate and tune up the software in live mode - while he is editing it - for two purposes - speed up the software development, or to reproduce bugs and stuff found on any of the other environments.