What You Need to Know About Dynamics 365 Finance and Operations ‘One Version’ and Development and Build Environments
We've provided some previous resources on how the more frequent updates to Dynamics 365 Finance and Operations 'One Version' affects users and your active system. However, you also need to consider how One Version affects your Development and Build environments too. Here is a couple of scenarios for how your instance could be set up with Microsoft and what your options are.
Scenario 1:
Microsoft standard offer with Microsoft subscription: three environments
- Your production environment
- a Tier-2 Standard Acceptance Test environment (UAT/Sandbox), and
- One Tier-1 develop and test environment.*
*Assume your Build server is hosted on your Azure subscription.
Scenario 2:
Multiple development, build and sandbox environments
Example:
- Production
- Dev Current Release
- Dev Next Release
- UAT Sandbox Current Release
- UAT Next Release Build
Customers can have multiple UAT/Sandbox environments BUT they can only pick one for Microsoft to update. The rest of the environments that were not updated by Microsoft falls on the customer to update. Microsoft only will update one sandbox/UAT and the PROD environment. The big takeaway of this concept is Microsoft is keeping your one SANDBOX and your PRODUCTION up-to-date. You are responsible for keeping your Development and Build environments updated.
So, what about your Development environment(s), and your Build environment, or your other UAT/Sandbox environment(s)?
Consider you have D365 Finance and Operations operating per scenario 1 above, where you have only one Sandbox environment and your SANDBOX is now on the newest and greatest version. It was updated by Microsoft per your Update settings in your LCS project settings. Your user then ran into an issue in PRODUCTION. You now don’t have a SANDBOX to refresh PRODUCTION to nor a SANDBOX environment that is a copy of PRODUCTION for you to do your testing and troubleshooting.
When your SANDBOX is at the new version with scenario 1’s topology, be aware that the code on your development environment (and build environment), will not have a SANDBOX environment to be pushed to since your SANDBOX and development and build versions are different. So, it is important that you keep the version in synch between all your environments
In order to avoid the above dilemma, you may choose to implement a code freeze period, concentrate on testing the new SANDBOX so you can get PROD updated to the new version on a timely manner and continue with code work. Also, another factor to be aware of is that you can hold off the One Version update for only so long. Or alternatively, you can implement an environment similar to scenario 2 above and have another Sandbox environment that is at the same version as PROD, Dev and Build environments. Scenario 2 will be an added cost to you and the cost will depend on the number of environments and the type of your subscription.
Lastly, when your PRODUCTION environment has been updated, consider updating your DEV and BUILD environments in a timely manner so you can continue with code work.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.