Environments for Projects

As as tech guy, I immediately know what someone is referring to when they’re talking about environments (within a technical context, of course). However there are a large number of (non) technical people who have absolutely no idea what the word ‘environment’ means, leaving aside how they are used.

The aim of this post is therefore to demystify what environments are, the different types, how they’re used, etc.

Caveat: There may be specific circumstances in which these may differ, eg for Dynamics F&O

So firstly – what is an environment?

This is simple to answer – an environment is a full (technical) system. There may be multiple different systems contained within the same environment (or they could be split out). There will be different environments used (more details below) in any company

Incidentally, people may also use the word ‘instance’ instead of ‘environment’.

The next question is – how are environments used?

Thankfully this is also simple to answer – environments are used to enable different parts of the technical system roll-out process. Each environment is unique (and should usually not be connected to each other

Types of environments

There are quite a few different types of environments needed. Listed below are the ones that are usually considered to be MVP (no, not Microsoft Valued Professional….in this context it means Minimum Viable Product)

Development
This is the environment that the development team will use for coding and configuration, as well as initial testing of code
Once code is stable, it will be promoted to the next environment

UAT (User Acceptance Testing)
This environment is where the client/business will access to test the system. Each development item will have a logged story, and these will be tested against. They will either pass (and then be signed off) or not pass (with explanations given as to why they haven’t passed) and be sent back to the development team

Note: It may be possible to use the UAT instance for training, and all client/business users to access it. This will depend greatly on the resources needed, project timeline/progress, etc. It is not usually advised to do this though

Staging
This environment is where data migration is tested out, to ensure that all data from the previous system/s are successfully migrated (with any transformations that may need to take place).

Note: It may be possible to combine the UAT and Staging instances, if the proposed system is very simple and not complicated/large

Production
This is the actual LIVE system for the company

Customisations, code etc are promoted through the different environments with releases. It’s important to ensure that these are carried out properly and scheduled in, especially when applying a release to a production environment. I’ll cover how this should be done, and what things to bear in mind, in a future post.

There are also several other types of environments that may be being used, depending on the type/scale/scope of the project:

Training
This is an instance with all customisations and code (to date) along with data that is used to train all client/business users. Any updates in functionality to test environments would need to be replicated to this environment as well

Integration
Depending on the other system/s that D365 will be exchanging data with (both in and out) it may be necessary to have a specific instance set up to test out the integration with these other components

Support
A clone of the Production environment for use in support cases eg attempting to recreate issues/bugs that have been raised

If you’ve come across any other types of environments, please do comment!