In this blog I want to explain how we do release management in one of our Microsoft Dynamics 365 for Finance and Operation implementation projects.
Our branching strategy includes a hotfix and release isolation which is similar to what is described here: https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/branching-strategies-with-tfvc?view=azure-devops#servicing-hotfix-release-isolation. This branching strategy results in a branch structure which you can see in the banner of this post.
All developers will check-in their changes with references to product backlog items or bugs to the main-branch. This changes (from the main-branch) get delivered to a test system, which we call development test (DevTest), every night. After the test is done on DevTest environment the tested changes can be taken into consideration for merge to the release-branch. Which changes will be merged to the release-branch is on outcome of our weekly release-meeting. As you can see in the following picture it´s possible that changes do not get merged even though they are tested, because they are currently too risky or they simply should get another testing round on the DevTest environment.
After merging all those changes to the release-branch, a release gets created and deployed to a pre-production (sandbox) environment for further validation/testing.
To track the state of the test tasks in this stage of the release management process I´m using a PowerShell script, I will share in one of my following posts. The script got some inspiration from this post http://calafell.me/identify-merge-candidates-efficiently-in-azure-devops-version-control/, but it uses a completely different API to query the needed information.
When all tests on the pre-production were successful and got signed off, we schedule the deployment to the production environment via LCS.
If you want to (re-)use the diagram from this post, feel free to download the PowerPoint slide deck here: OneDrive