Deployment Tasks – CI / CD Part 4

Deployment Tasks – CI / CD Part 4

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:

PowerShell Script Task

Richard Robberse provide with Build-as-a-Service an integration for Azure DevOps too. His offering target to C/AL, AL and Hybrid and provide a complete scenario.

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

ALOps Azure DevOps Extension

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.

PowerShell Script Task

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.

ALOps Task Parameters

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:

  1. Go to the Marketplace
  2. Search and Select an Extension
  3. Install the Extension
  4. Setup the Payment (when needed)

The result may look:

Es wurde kein Alt-Text für dieses Bild angegeben.

Artifact Deployment

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.

Es wurde kein Alt-Text für dieses Bild angegeben.

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:

ALOps-Publish SaaS
ALOps Publish SaaS Parameters

Some needed configurations / parameters are described in the post of Dmitry Katson:

How to create Business Central Online Sandbox with API. AAD Authentication

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:

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)
  • Hotfixes

ALOps Import FOB with a few parameters can import these object files:

ALOps FOB Import
ALOps FOB Import Parameters

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)

ALOps Publish
ALOps Publish Parameters

What’s next

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.

Additional information from previous Posts:

Share

Leave a Reply

Your email address will not be published. Required fields are marked *