All we need are Tasks to deploy our Artifacts at Microsoft Dynamics 365 Business Central SaaS or On-Prem. In this article I’ll share with you a deeper look into my deployment stages.
CI/CD Pipeline Tasks for MSDyn365BC
Azure DevOps provide lots of build-in tasks to execute almost everything in the context of a Build or Deployment Agent. Unfortunately, pre-configured Pipelines or Tasks for Microsoft Dynamics 365 Business Central are not part of this list. However, there are other good options
Freddy Kristiansen posted in the past a lot of examples and tutorials in his Blog to build and publish Artifacts (the App) to the MS Dynamics 365 Business Central (SaaS). His pipelines uses PowerShell Script Tasks and these PowerShell scripts are part of the Git-Repository, provided as HelloWorld project.
From my point of view a very good start to get familiar with CI/CD and learn what happens in the background. Almost everywhere you can use a PowerShell Script Task in a pipeline:
During my own adoption of this technology with lots of PowerShell scripts and writing of Azure DevOps extensions I found a Tweet from Eric (waldo) Wauters. He announced another set of CI/CD Pipeline tools for building Business Central Apps: ALOps
PowerShell Script Tasks vs. Tasks from Azure DevOps Extension
PowerShell tasks give you a great flexibility, are easy to add and to adjust. Using scripts files in a Repository with parameters instead of inline PowerShell commands improves the readability. A good approach for a few projects but you need to maintain these scripts manually.
Tasks from Azure DevOps Extensions need only parameters. They will be deployed by installing the marketplace extension and update automatically. This is currently my prefered scenario, because we have to setup and maintain a lot of projects in the future.
Azure DevOps Extensions
Extension can be installed at organization level and will be paid by your configured Azure Subscription. Some extensions are free some not. To install an extension:
- Go to the Marketplace
- Search and Select an Extension
- Install the Extension
- Setup the Payment (when needed)
The result may look:
My Artifact(s) are created by CI and each Artifact contains the App, the Test App and in case of Hybrid (I’ll try to avoid this) a FOB file.
In CD release pipelines I prefer to use ALOps Tasks (Azure DevOps Extension). My decision is based on the maintainability of pipelines as well as reducing copy-paste overhead which messes up my Git repositories.
Tasks for SaaS Deployment
In my last post I described, which Agent is needed to execute a SaaS deployment task. There is no access to the SaaS environment, therefore I use an Agent Job with a build-in agent from Microsoft:
Only one task is needed: ALOps SaaS Publish Extension. The parameters are self describing:
Some needed configurations / parameters are described in the post of Dmitry Katson:
Tasks for On-Prem Deployment
On-Prem deployment need access to the target environment. I use Deployment Agents and configure these agents with tags. Now it’s easy to select the right server in a Deployment Agent Job:
C/AL and C/Side are deprecated. BUT, until all of our customers are using the latest BC version and FOB’s will leave the stage, we have to import good old object files. The reasons may be:
- Hybrid Development
- Products (provided as FOB’s)
ALOps Import FOB with a few parameters can import these object files:
My main deployment is the app-file and I use ALOps App Publish to deploy it to the NST. The App is published, synchronized, data upgrade executed, and installed automatically when a higher version is deployed. (more about Versioning in the next post)
After Directions EMEA i’ll continue my series… With some a post about my Artifact Versioning and my Branching concept. Finally I’ll share some insights, why I use Universal Packages and “Badges”. So, stay tuned!
I like to read your comments, suggestions, and be curious if this fits into your process.