Designing platform environments

While we're preparing our development environment, it's a good time to talk about planning our platform environments (in an on-premises or IaaS system, we may say server environments). These environments are used to host our system during the different phases of their life cycle between development and production (or live).

The scales of a business and budget are the major factors in this decision process; if we have a large business and a large system, it might take a number of testers to test the changes made to a system and do full regression tests when needed. If the budget for a system is tight, it may not be possible to have a perfect set of environments, so compromises may have to be made. We also need to remember that we're not just talking about a single website; we need to include databases, table storage, worker roles, Service Bus queues and topics, and so on. We'll look at different types of environments and examples of environment sets for different types of businesses, and then have a look at a couple of Microsoft Azure features that are relevant to this.

Common environment roles

We're going to take a look at four common environments you may find in IT systems in any business and their role in the application's life cycle:

• Production environment: The production environment is where the system is published once it has passed all testing phases and is ready to be used by the end user, which could be the general public or staff within an organization. This environment will be allocated the most compute resources and scalability of all the environments; however, some businesses (where financially allowable) like to have a test or QA environment matching production exactly so that the system performs the same as in production to help gather realistic load testing and performance statistics.
• QA environment: Typically, before a system goes into production, the end user will want to test it to make sure that it meets their requirements (commonly against a specification) and doesn't have any bugs, which will affect the running of the business. QA environments can also be used for training as they often closely match the production environment.
• Test environment: After a system is developed, it is always tested by a dedicated test team or by the developers themselves, if a business does not have a test team. In a small business, as a minimum, there should be a test environment before production to not only allow independent testing but also to prove that the system can be taken from a developer machine, where a system was created, and published on another environment without problems, a bit like a dress rehearsal!
• Development/Integration: The development environment is where developers can do pretty much what they need to develop the system, prototype new things, and work out how to put a system together without going anywhere near a production system. If the environment is on-premises, these are not ideal environments for testing as there are often developer tools such as Visual Studio and developer SDKs to help debug applications and elevated privileges, which can be an unrealistic representation of the production system. In Azure, this is not the case as we are often deploying a PaaS solution to develop against and not installing tools or altering permissions on the infrastructure. When we're talking about the development environment, we're talking about a development sandboxed server environment and not about the local machine that the developer writes code on. If we implement continuous integration, this is an ideal environment to deploy to.

Example environment sets

To put these environments into a context, we'll have a look at how these different environmental requirements can be sensibly implemented in businesses of different sizes and requirements:

• Small business: In a small business or for personal projects where there isn't the budget or time to build, manage, and use more than a few environments, it's probably sensible to have a multipurpose development/test/integration and a production environment, as shown in the following diagram:
  

  Systems can be developed locally and then published to the test environment for all phases of testing. If an end user needs to perform a QA test, it's important that the developers don't publish changes during testing cycles to avoid disrupting a test. If a continuous deployment strategy is deployed, where a system is published as code is checked in and built, it is extremely important to make sure this is disabled during testing if active development is underway.

• Medium business: In a medium business, which has a testing team or more stringent requirements for QA testing, it's good to separate the test and development environments so that QA and system tests can be performed in complete isolation from the development environment, as shown in the following diagram:
  

  This means that the development team doesn't disrupt the test environment and their normal work activities aren't impacted during test cycles. Another advantage of having the extra environment is that the development team can work on a different version of code to the one being tested, which is helpful for productive release management.

• Large business: Large businesses that have a testing team and require a permanent QA environment for end user testing and training may require another dedicated QA environment, which is only used by end users and not system testers, as shown in the following diagram:
  

Using website deployment slots

Website deployment slots are a new feature (currently in preview), which allow a staging slot to be added to a website, allowing changes to be tested in a mirror of the production environment, and then swapped with a live environment when ready. There is also a nice feature, where the site is warmed up before it's put into production, so there is not an initial performance hit caused by a cold website start.

We need to be careful about how we use website deployment slots as there are a few things that may catch us out:

• Some configurations including general settings, connection strings, handler mappings, and monitoring and diagnostic settings are copied across on swap, so we will end up using the same database and diagnostics storage in staging, as with production, if we don't manually change them before swapping
• Deployment slots currently run on the same VM as production, so anything you do on a staging slot, whether it's UI testing or load testing, will have an impact on the performance of the production system

For medium and large businesses, I would recommend that you use a deployment slot in the production environment, purely to get the benefit of doing a final touch test (checking site runs, looking at read-only data, or working on data for a special test account) and doing a warm swap into live. I would not use it for a QA environment due to limitations of website configuration and VM resources, as mentioned in the preceding bullet list.

For a small business or personal projects, it might be a good option to use a deployment slot as a test environment; however, you may prefer two separate websites on a FREE service tier to save the cost of having one on a STANDARD tier.

Using cloud service staging environments

Web roles and worker roles have staging slots by default, which in contrast to website deployment slots, have separate configurations that aren't swopped and run on separate instances. When a swap occurs, the virtual IP address of the production and staging VM is swopped, so staging becomes production and production becomes staging.

A staging slot can be used as a QA or test environment to streamline the deployment process; however, you will still need to update the staging environment to the production version after a swap.

If the staging slot is only used in the production environment, it can be deleted once it is successfully swopped with the live environment, to save on compute cost.

For large businesses that require a full set of application environments, I recommend that you use the staging slot as part of the production environment to expedite the deployment process and also have a regression plan available (swapping back again to the previous live deployment), in case any problems are found after go-live.

For medium and small businesses, I recommend that you consider using the staging slot as a QA or test environment.