Managing environments for your cloud deployments

One of the first technical decisions you will make at the start of a cloud-based business application project is the management of your software environments. You need to think about how many instances you need for configuration, development, testing, training, and staging to get to the production. Each type has a different life cycle and characteristics. The more environments you create, the more work you must do to sync them up. Having a good plan upfront will save you some headaches later.

For development, you are going to need multiple environments to enable simultaneous work. These environments are created at the start of the project. Some will exist even after the go-live, for continuous improvement. They are used for configuration, customization, integration, and data migration. They are smaller in size and need to be connected through a code management tool - such as Azure DevOps (formerly known as Visual Studio Team Services). These development environments then feed a single testing environment.

The testing environment is larger in size and is created at the start of the project also. It stays on during and after the project is completed. It is used for end-to-end testing. Even though unit tests can be conducted within the development environments, the merged code needs thorough testing by the larger project team in a single environment. During the project, this also becomes the hub for the pristine configuration of the solution.

Toward the end of the project, you are going to need a training environment. As you open the solution to more users, they need a separate environment to learn the solution. This is also large and stays on until the go-live. It is a controlled instance with specific training data. It is refreshed regularly with the latest configuration settings.

As you are approaching the go-live, you need to create two environments: the staging and production environments. Both will stay on after the go-live. The Staging environment is small and will maintain the latest code base and settings to be promoted to the production environment. The Production environment is the largest one and is tightly controlled by the software vendor.

In large projects where transaction volumes are high, you may need to boot up a performance testing environment. This is generally a large environment that resembles the production instance. You will use it for a brief period towards the end of the project to ensure the scalability of the solution.

The movement of code, settings, and data across these environments requires a highly coordinated effort. You may end up creating multiple build environments to keep track of different versions of the code: what is live in production, what is being tested, what is being developed, etc. You need to consider which environment keeps the pristine settings, how frequently code needs to be merged and distributed, how to store setup, testing, training data packets, etc. It is a best practice to write down your procedures upfront before rushing into creating a bunch of instances.

So far, we focused on the environments for the software you are deploying. In addition, you need testing environments for the software you are integrating to. You cannot use production environments to test integrations to your new solution.

If you are interested to learn more, please connect with me on LinkedIn, follow me on Twitter, or watch me on YouTube.

My name is Cem and this has been another gem.