Personalized Community is here!
Quickly customize your community to find the content you seek.
Now Available in Community - New TechTalk Videos for 2020
Read More about New TechTalks for 2020
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 2 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
This blog describe the best practises and guidelines for using Azure DevOps for Azure Integration development and release management.
Figure 1: High Level view of AIS Release management
For releasing software to other environments, three different branches are used.
Figure 2: Branching strategy for AIS
Dev: The dev branch is used by developers to check-in all pending changes in Azure integration solutions.
Main: The Main branch is used by the release manager to merge all changes from the Dev-branch once these changes are tested and approved by the Tester. The artifacts from this branch will always be used to deploy the solution to Test, Acceptance and Production environment.
Release: The release branch is created by the release manager once Azure integration solutions for the current iteration are approved. The latest version of the release-branches can be used to apply hotfixes on the current release.
Check-in Policy in DevOps: Every check-in (Change set) must be linked to a related Task or Issue in the DevOps
Naming convention for Release Branch Release Branches should be named with the combination Business Release Number and date of the release in the format of YYYYMMDD
Naming convention for Release Branch
Release Branches should be named with the combination Business Release Number and date of the release in the format of YYYYMMDD
The following merging guidelines should be followed during code merge
The merging of HotFix changes is merged manually. The HotFix engineer should communicate the fixed to the DevLead of the project. The change information should be clearly communicated with information such as : The actual change, DevOps issue ID, the changeset number. The Hotfix engineer should ensure that he/she receives confirmation from DevLead that the change has been merged. The DevLead of the project should check-in the change with the correct issue id from the DevOps.
The merging of Dev changes is merged to Main. The Release manager of the project should merge the changes and link all the changesets and DevOps Tasks/Issues, which are part of the merge. This would help to create a Technical release document with all the features/issues which are included in the release.
Two different build pipelines are available:
Build-Main: Manual build for Main-branch.
Release Build: Manual build for Release-branch.
Two different Release pipelines are available:
Release-Main: Release pipeline for Main-branch.
Release Hotfix: Release pipeline for Release(Hotfix)-branch.
Resource group management. The following would be the recommendation for resource group management for Azure integration.
Business Applications communities