Some organizations utilize a staging environment to replicate the production environment. This staging environment can be used for several different purposes, including determining potential problems in the production environment and as a replacement when the production environment fails or is compromised. It is also used when implementing a blue/green deployment (see the following section for more details).
When using a blue/green deployment, you have two identical environments: production and staging. The production environment is live and used actively within your organization. The staging area is used in the final phase of deploying a new version of the solution. This means that changes made within your QA environment are applied to the staging environment, and some final tests are performed.
After tests have passed successfully, the staging environment is converted into the production environment, and the production environment is now treated as the staging environment. If the solution still runs smoothly, changes made to the original staging environment are then applied to the new staging environment. The result is the two environments are identical again.
This process is called a blue/green deployment because one environment is traditionally labeled “blue,” and the other is traditionally labeled “green.” Note that either blue or green can be the production or staging environment at any given time.
The advantages of using this method are smoother upgrades, less downtime, and the ability to quickly roll back a deployment to a previously working environment. The disadvantages of this system are the additional costs and time to maintain both environments.
A DR environment is used specifically if the production environment is compromised. While a staging area can sometimes be used for DR, it is not an ideal DR solution because there are times during a new deployment that it is not identical to a production environment.
A DR is an identical copy to the production environment that has one specific purpose: a quick way to restore a compromised environment. Typically, the DR environment should be located in a different geographic location than the production environment so a physical disaster cannot disable both environments.
Expect scenario-based questions designed to test your ability to determine which development environment is the best solution for a given situation.
When an organization develops software and the software is released, either internally or externally, the release is referred to as a build. This section explores different types of builds.
A stable release is designed to be a release that is ready for a production environment. Typically, if you are a customer who purchases software, that software is considered a stable build.
Prior to a software build being released, earlier releases are called beta builds. Some organizations like to have access to beta builds because this provides them with early insight as to how the software will perform. However, beta builds come with little to no support or warranty. They are considered “use at your own risk” and should not be used in production environments.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
