In D365 FO Environments – Part 1 I talked about the challenges that Technical and Solution Architects face when it comes to environment planning and how important it is to do that as early in the process as possible and preferably in the sales process.
In Part 2 I will discuss the different environments and what pros and cons it has to deploy environments in a given way. What is SIT, SAT, UAT, Playback, Gold, Buld, Prod etc.
In a fairly big implementation that we can put somewhere just above being in the middle of the complexity scale having the following environments will get you quite far if not all the way. Like I mentioned in part 1 each implementation has its own flavor, twists and turns.
So, what are the environments that we can get quite far by deploying those?
The table explained
Each row in the table represents one environment type so in this case we have 12 different environments.
The development environments are a single box deployment that is the server includes everything that Dynamics 365 for Finance and Operations needs to run e.g. SQL database.
The Roles environment is used to configure the role based security based on the roles that the implementation team has identified. Data from the Data migration master config environment is lifted to the roles environment to conduct security testing there
Master config / Golden
This will be used to hold the master data configuration of the solution and must be available to application users involved in the configuration process. Modifications for the master data configuration are migrated from the DEV instance into the MST instance. No business processes will ever be run in this instance, and subsequently this instance will never contain any transactional data.
The data migration instance is used to facilitate the migration of data in accordance to the requirements of client. All users working with the data migration must have access to this environment Data model changes required for the data migration process will be released from the Development instance. Data from the Master configuration is moved over to the Data migration before data from the data migration is imported.
This environment is also often called “Functional Acceptance Testing – FAT” and this environment is used for the first stages of testing and also playback of all modifications that have been finished in a given sprint. The playback is done for the solution stakeholders and it is a checkpoint for the modifications to progress further in the delivery process. I will later do a special blog on the code delivery process
User Acceptance Testing – UAT
Promotion of objects into the UAT environment is decided and governed by the delivery cycle of the implementation. Created from a copy of the master data instance, including all the data from the data migration instance for migration test purposes and signed off modifications and configuration from the SAT / SIT instance, this will then be populated with sufficient standing & transactional data to support user acceptance testing.
As the name implies this environment is used for training purposes and in big and complex implementations there is often a need for two, three or oven more separate Training environments. The purpose of that is to make sure that parallel training sessions will not interfere with each other. Before training can start all the latest data migrations and configurations as well as code is deployed to each training environment.
System Acceptance Testing – SAT and System Integration Testing – SIT
Promotion of objects into the SAT environment is decided and governed by the delivery cycle of the implementation, created from a copy of the master data instance and signed off modifications from the test instance. System integrations can be done in this same environment as the SAT. If that will proof to cause any issues while in the implementation phase it is a new environment can simply be deployed to separate the two.
Build – Port of the standard subscription
The build environment is used to do code builds of the code checked-in to the code repository that is hosted in Azure DevOps. All kinds of automatons can be setup in DevOps to handle code build and deployments and you can expect a blog on that later.
Test – Port of the standard subscription
General test environment used for testing code and it is up to the implementation team the TA and SA to decide exactly what purpose this environment has
Production – Port of the standard subscription
This is the actual live system that the client will start to use at the end of the implementation process and the system that the Microsoft partner supports post go-live. There is also a quite bit that can be said about the environments that are needed when a client goes from implementation phase over to support phase. Or like is some cases there is a multi step go-live strategy and then the environment landscape takes a whole another picture
In the third and last part of this blog series I will talk about the difference between the tiers that environments can be deployed into and what the difference is between Azure cloud hosted to LCS cloud hosted environments.
Until then have a fantastic time implementing Dynamics 365 and supporting your customers