Implementing Simple CI/CD for Dynamics Solutions

When dealing with multiple instances of Dynamics 365, it becomes paramount to incorporate source control for the unmanaged solutions under development, alongside establishing robust CI/CD processes responsible for seamless solution transfers. Failing to do so could result in version and content discrepancies across environments, the emergence of undesirable active customizations, and potential future complications with customizations and data import.

Fortunately, Microsoft has taken significant strides by providing all the necessary tools and comprehensive documentation to delegate the CI/CD process of Dynamics Solutions to Azure DevOps. This effectively mitigates the aforementioned issues, while offering a more controlled and convenient solution migration process. Embracing these solutions enables you to stay in sync, reduce risks, and foster a smoother workflow in your Dynamics 365 endeavors.

Let’s dive into a minimal example that will serve as your launchpad. To get started, you’ll require the following essentials:

• Two Dynamics instances: one is the source of customizations, and the other one is the target.
• Application users in both environments, having either the System Administrator or System Customizer role.
• An Azure DevOps environment that will house the source control for your solution. This platform will also host the build and release pipelines for your CI/CD workflow.
• Microsoft Solution Packager tool (which can be found here).

Workflow

The CI/CD process for Dynamics 365 unfolds as follows:

1. Changes : The developer starts by making changes to an unmanaged solution in the source environment.
2. Export and Unpack : After finalizing the changes, the developer exports the unmanaged solution and then unpacks it using the Solution Packager Tool.
3. Source Control Management : At this stage, the developer thoroughly reviews the changes made to the source code. If any undesired alterations are identified, they are promptly removed. The developer then commits the changes to Azure DevOps, ensuring a well-maintained and organized version control.
4. Automatic Build Pipeline : This is where the automation comes into play. The automatic build pipeline is triggered, harnessing the power of Microsoft’s provided Power Platform tools to build the source code into a managed solution.
5. Publishing the Artifact : The result of the build process, the managed solution, is published as an Artifact. This serves as a neatly packaged and deployable unit, ensuring consistency and reliability.
6. Automatic Release Pipeline : As the final step, the automatic release pipeline springs into action. It imports the managed solution into the target environment, bringing your latest customizations and improvements to life.

To summarize, the first three steps of the CI/CD process are done manually by the developer, where they make changes, manage source control, and commit the changes to Azure DevOps. The subsequent steps, on the other hand, are automated by Azure DevOps. Embracing this CI/CD approach, you unlock a world of productivity and precision in your Dynamics 365 solution development process.

Source Control

After the developer has made changes to the unmanaged solution, the next step is to export it from the source environment and unpack it. While this process can be done manually, you can take it a step further and achieve automation using PowerShell and CMD scripts. In fact, I have created a .NET console application that seamlessly handles the export and unpacking of solutions. In my work, I have created a .NET console application that manages the export and unpacking of solutions.

Let’s begin by leveraging a PowerShell script to download the desired solution. To get started, make sure you have the Microsoft.Xrm.Data.Powershell package installed, as it plays a crucial role in authenticating and interacting with Dynamics:

Install-Module -Name Microsoft.Xrm.Data.Powershell 

Next, we will download the solution:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Import-Module Microsoft.Xrm.Data.Powershell

$CRMConn = Get-CrmConnection -ConnectionString "AuthType='ClientSecret';ServiceUri='https://dynamicsurl.dynamics.com';ClientId='clientId';ClientSecret='clientSecret';"

Export-CrmSolution solutionName solutionPath -SolutionZipFileName solutionZipFileName -conn $CRMConn

Finally, unpack the solution into the source control folder using the Solution Packager Tool:

SolutionPackager.exe /action:Extract /zipfile:mysolution_1_1_0_0_managed.zip /folder:source /allowDelete:Yes

I recommend using the following structure for your source solution:

In this exemplary setup, the project structure is organized into various components to streamline the CI/CD process for Dynamics solutions. Here’s a breakdown of the different components and their roles:

Plugins :

• This project houses the plugins that are developed and intended for publishing to the Dynamics instance.

Infrastructure** :**

• The Infrastructure project holds all the essential resources needed to facilitate automation and the CI/CD workflow.
• It contains PowerShell and CMD scripts that are utilized in different stages of the process, such as exporting and unpacking solutions.
• YAML files for pipelines are present, defining the build and release processes to be followed during CI/CD.
• The Solution Packager application.

Retriever:

• The Retriever application acts as a central tool, orchestrating the downloading and unpacking of solutions using the scripts provided in the Infrastructure project.
• It simplifies the process for developers, allowing them to interact with the solution management functionality seamlessly.

Solutions folder:

• This folder is a repository for all solution-related source files, encompassing both managed and unmanaged solutions.
• Developers can find and manage their solutions within this folder, ensuring a well-organized and version-controlled environment.
• Managed and Unmanaged solutions here are readily available for publishing to the target environment.

Automation

Once the source code for the solution has been published, the Build pipeline on Azure DevOps plays a crucial role in ensuring the integrity of the solution. This pipeline is responsible for building the solution from the source code and pushing it to Artifacts, where it can be easily managed and deployed. To leverage this functionality in your DevOps instance, you’ll first need to install the Power Platform Build Tools from the Azure Marketplace.

You have the option to utilize Pipeline snippets for building and pushing the solution, and for more extensive customization, custom YAML scripts can be employed. The simplest example involves three essential steps:

1. Install Power tools : This critical step imports the Power Platform Build tools into your pipeline, enabling their functionalities.
2. Pack Solution : Here, the source folder is built into a managed solution, ensuring it is valid and prepared for publishing. Remember that the agent for your pipeline must be Windows for the Packager Tools to work!
3. Publish Artifact : In this step, the final managed solution is pushed into the pipeline artifacts, making it import-ready.

By following these three steps, your CI/CD pipeline is well-equipped to handle the build and publishing processes for the managed solution, streamlining the deployment into the target environment.

To enable the automatic import of your solution into the target environment, you’ll need to create a release pipeline. Go to Azure DevOps and navigate to the “Releases” section, then create a new pipeline. In the release pipeline editor, click on “Add an artifact” to specify the source from which the release will be triggered. Choose the appropriate build pipeline that you previously created as the source of your artifact. This ensures that whenever a new build is available, it triggers the release pipeline. After adding the artifact, go to the “Continuous Deployment Trigger” section for the artifact. Enable the trigger on the specific build pipeline you want to use. This means that whenever a new build is available in that pipeline, the release pipeline will automatically start.

In Stage 1 of your release pipeline, you will create a new job and add four tasks to achieve the following:

1. Install Power tools : This task will import the Power Platform Build Tools into the pipeline, similar to what was done in the Build pipeline.
2. Solution Checker : Utilize this task to validate the solution components for their correctness. It will analyze various elements, such as custom workflow activities, web resources, SDK message steps, Power Automate Flows, Power Fx expressions, and more
3. Import Solution : In this step, the verified solution will be attempted to be imported into the target environment. Prior to this, ensure you have set up the Service Connection to your environment. Use an application user and provide its Client Id and Client Secret to Azure DevOps.
4. Publish Customizations : As a best practice, after importing a solution into the target environment, it is essential to publish active customizations in the target solutions.

After setting up your CI/CD pipelines, it’s time to put them to the test. In your source Dynamics 365 environment, make some changes to the unmanaged solution that you want to test. Export the unmanaged solution either using the script you previously set up or manually through the Dynamics 365 interface. Use the Solution Packager tool to unpack the exported solution into the source code. Commit the changes to the source code to your Azure DevOps repository.

The build pipeline should automatically trigger upon the commit to the repository. The solution will be built using the Power Platform Build Tools and published as an Artifact. The release pipeline should be automatically triggered after the build pipeline successfully creates the Artifact. The release pipeline will import the managed solution into the target environment using the configured service connection and credentials. Keep an eye on the pipelines as they execute. Check the logs and outputs to ensure that there are no errors or issues.

Once the release pipeline is complete, check your target Dynamics 365 environment to confirm that the managed solution has been imported successfully and that any customizations are correctly published.

If all the steps are executed without any errors and the target environment reflects the changes you made in the source environment, congratulations! Your CI/CD setup is working as expected. Now you can enjoy a streamlined and automated solution deployment process with minimal manual intervention.

In case you encounter any issues or need further assistance, don’t hesitate to ask for help. Happy testing!

Written by Kyrylo V.

Kyrylo is a certified Microsoft Dynamics developer with rich experience in Power Platform and 5+ years of hands-on experience in developing custom Dynamics solutions for clients across various industries.

The post Implementing Simple CI/CD for Dynamics Solutions first appeared on Hire Dynamics Developers.