This is another piece of critical information that we need to include in our TDD. Based on the project complexity, the solution architect provides development environment setup details. A simple setup can be used for less complex projects, in which one or two developers are working on the same development instance and their own set of entities. Later, these changes can be promoted to a quality assurance (QA) environment after unit testing. In this approach, developers need to be careful when selecting their entities, to ensure that the other developer is not working on the same entities.
On the other hand, there can be multiple development instances for developers, based on project complexity. All of the changes that are from the individual developer instances can be merged into a master development instance, and from there, it can be promoted to a QA or a system integration environment (SIT) environment. Microsoft Knowledge Base (KB) for solution life cycle management can be used as a reference document to set up development environments.
Keeping the HIMBAP Auto Service Center implementation, we can use the following simple development environment approach:
Developers can work on a single development instance and, from there, the solution will be released to a QA environment after unit testing. Once QA and user acceptance testing (UAT) are complete, the solution will be released to the production environment. All of the code and customization will be included in the development solution and can be promoted as an unmanaged solution to all the environments. We are going to discuss unmanaged versus managed solutions in Chapter 6, Customizing Dynamics 365 CE. We can understand solution release management with the following flow chart:
A development solution will include all of the components such as entities, workflows, and plugin assemblies (we will be discussing solution components in detail in Chapter 6, Customizing Dynamics 365 CE). Once development is over, we will export the unmanaged solutions and check the solutions, as well as our code, in source control. The exported unmanaged solution will be imported to the target environment. If the import is successful, changes can be committed to source control. If it is not, any solution issues can be fixed, and the deployment process can be restarted.