Environment Management: Unlike what one might assume, modern software is not built and released in the same place. Suppose a developer is writing and testing code in a localized and controlled development environment; the code may then be moved to staging for wider testing and ultimately released to production for its final users.
These different environments all serve various purposes and have different work, but the common thread lies in the fact that they all behave in predictable ways. A problem or defect is often brought out when an application works during the development process but fails during the staging or production stages since the environment utilizes different settings, software versions, services, or permissions.
Environment management refers to the process of keeping these release environments organized in order to make sure that the code, configuration, and other aspects of the application are handled correctly. Modern development practices encourage a separation between the configuration and the code, as can be seen with the Twelve-Factor App Methodology that recommends keeping variables outside the domain of the code.
Development Environment
The development environment refers to an environment where developers are able to build as well as test out new features. It is the least restrictive of the environments since developers require freedom to experiment with trial-and-error, make changes, and encounter problems.
A development environment may use a local database, test accounts, sample data, development APIs (Application Programming Interfaces, and various debugging tools. These settings should be clearly segregated from production settings.
For instance, an application may connect to the following:
- A local database before development
- A test database during staging
- A production database following release
The application need not employ a completely different set of code for each of the cases. Instead of completely rewriting, the database address and other changing values can be supplied through configuration.
This approach allows the easier movement between environments for the same application. It is also important for development environments to avoid operating while making use of legitimate production credentials. A developer whose work is limited to testing out an application should not be granted automatic access to sensitive data from production systems.
The goal is to create an environment where developers can quickly get done with their work without creating some sort of security risk or a deployment issue for production.
Environment Management Guide: Staging Environment
Staging is the process that lies between development and production. The purpose of a staging environment is to provide a place to test a release under conditions that are eerily similar to the live system it is being made suitable for.
The staging step is extremely important since some problems are overlooked during the development phase. It may depend on any of the following factors: network settings, database behavior, authentication, infrastructure, or the way the services communicate with one another. These problems get triggered by system complexities rather than from the isolated local code.
Another crucial aspect to note is that a useful staging environment should ideally use the same application build that is intended for production, whenever possible. The supporting systems should also preferably be similar enough so as to expose the problems that actual users will be encountering.
However, it is important to bear in mind that staging does not require the same scale as production in most scenarios. Therefore, for that reason, the company may use fewer servers and smaller databases in the staging step since its purpose is conducting tests rather than dealing with real consumer traffic. Staging can very well be the final checkpoint before release. Automated tests can continue running on the application, while the team intervenes specifically to conduct the manual checks as and when required.
Modern deployment tools can easily add additional control around environments. The primary importance of this stage is to reduce the jump from tested and ready to live.
Production Environment
Production refers to the environment that is useful for real users and real workloads. Since a mistake in production can immensely affect the direct customers, data, revenue, or business operations as a whole, this stage requires stronger controls than both the steps of development and staging. Production deployments are urged to employ strict rules regarding who can deploy, what all can be deployed, and what checks and tests must be passed first.
For example, an organization may need the following during this stage:
- Successful automated tests
- A specific application version
- Approval before the deployment
- Accurate production configuration
- Access to only required production secrets instead of all
Deployment history is also extremely valuable. Teams should have a clear and concise idea of which version was made out to release, when it was released, the timeline for the process of release, and which environment received the release. Hence, production should be treated as a highly controlled and crucial environment rather than simply a place where the code is scheduled to be uploaded next.
Conclusion
Good and proper environment management is not simply about possessing the various different servers for development, staging, and production. It is also about creating a reliable path for the software to move during its journey from development to real users.
The different steps have different sets of responsibilities and goals that they aim to accomplish. Development should provide the freedom required to build and experiment at the same time. Staging serves as a realistic place to test releases. And finally, production provides controlled and secure delivery to the users.
The strongest release workflows make these practices repeatable rather than dependent on a team member remembering a manual step. When environments, secrets, and configurations are all managed successfully with adequate care, teams are able to release software with greater confidence and fewer last-minute alterations.
(Source)