In my last article of the CI/CD series I explained which package types I use to upload my Artifacts. As you can imagine, this is just one piece of the puzzle in my release management workflow for Microsoft Dynamics 365 Business Central.

More important for me is the correct traceability of my artifacts. In other words, this is the key to keep control over my projects.

As a result, I track each of my Artifacts respective to each deployment stage. You may wonder why, but I need to know at any time the version of my artifacts in a certain environment.

Furthermore as you see in the picture, I love to visualize important deployment information. In detail, the most interesting facts for me are artifact versions in relation to my staging environments.

You think that’s a lot of work? No – all this is out-of-the-box provided by Azure DevOps.

Artifacts, Feeds & Views

My Artifacts are packages (Apps, FOB’s, …) and follows all the same rules in my release management process. I use release pipelines to deploy them into Stages of my ERP System:

In OnPrem scenarios, each of my stages are NST Instance & Database. On the other hand in case of SaaS, my stages are Sandboxes or Production Tenant.

Artifact Feed

I store all my Artifacts in a Azure DevOps Artifact Feeds. That is to say, my central storage for my files. As you already know, these files are for example the output of my CI-Build processes, 3rd party apps, FOBs, or Rapid Start Packages.

Artifact Feeds in Azure DevOps are scoped. Therefor, I can create and use a project-scoped-feed in addition to an organization-scoped-feed. A project-scoped-feed is a good choice for most of my projects.

Note: Microsoft introduced scopes in November 2019 (Release Notes).

Additionally, I can add upstream sources for external package sources to my Artifact Feed. This allows me to manage external dependencies in a single feed. Per example, this is useful in multi-project or multi-region scenarios.

In my opinion, Microsoft should integrate also App-Source as an upstream source in the future.

Artifact List

If I select my artifact feed as follows, all artifacts of the feed will be listed:

This overview display all artifact packages from the feed. I get information about the latest version as well as the current stage (column: view) of my package:

Artifact Feed Views

Views are a part of an Artifact Feed. Each feed is created by default with 3 views: “Local”, “PreRelease”, and “Released” and Artifacts are promoted to views.

My release management workflow uses such views. It allows me to seperate and track my Artifacts within stages. Therefor, I prefer to rename / setup (Artifact Configuration) all stages as Artifact Views as follows:

As you see, I also keep the “Local” view as default. This is because I track the reached stages within a view. To clarify, I promote my Artifact when it has been successfully deployed in an environment by my CD pipeline.

First of all each created Artifact is visible in view “local” after upload per example by CI. Afterwards, I deploy with my release pipeline my Artifact into “Development” environment. Therefor, it is visible in view “DEV”.

I use a time based trigger for the next stage. Therefor, my release pipeline deploy the artifact each morning into “Quality Assurance” environment. Consequently I see the success within promotion to “QA” view.

Afterwards, our consultants can run per example manual tests and approve or decline the Post Approval. As a result, my release workflow is continued or terminated.

In the same vein, I use the “UAT” view for “User Acceptance Test” environment as well as “PROD” view for “Production” environment. As you already know, the key players for this stages are the key users at customer side.

Artifact Promotion

I don’t want to promote artifacts manually. Therefor, I use the task “Promote Artifact“ from Azure DevOps Marketplace in my release pipeline:

Once added to my pipeline, I configure the needed information. For most parameters I use variables. For example, my configuration for PROD view promotion is:

Another option is to update the package version by using the Azure DevOps API from PowerShell.

To promote my universal package “scm” (project scope), I use these variables in my CD release pipeline:

My promotion task (PowerShell) call the Update Package Version API for Universal Packages as follows:

$headers  = @{ "Authorization" = "Bearer $(System.AccessToken)"; "Content-Type" = "application/json"; }
$uri      = "https://pkgs.dev.azure.com/$([string]::Join("/", ([uri]$env:SYSTEM_TEAMFOUNDATIONSERVERURI).Segments[1].TrimEnd('/'), $env:SYSTEM_TEAMPROJECT).Trim('/'))/_apis/packaging/feeds/$(ArtifactFeed)/upack/packages/$(PackageName)/versions/$([version]::Parse('$(PackageVersion)').ToString(3))?api-version=6.0-preview.1"
$body     = @{ views = @{ op = "add"; path = "/views/-"; value = "$(ReleaseView)" } } | ConvertTo-Json -Compress
Write-Host "Get packages from '$uri'" -f Gray
(Invoke-WebRequest -Method Patch -Body $body -uri $uri -Headers $headers -UseBasicParsing)

Note: My API call uses the bearer token from $(System.AccessToken). This must be enabled at the Agent Job as follows:

During promotion to PROD view my PowerShell script sends this JSON payload:

{ "views": { "op": "add", "path": "/views/-", "value": "PROD" } }

As result , the used version of my Artifact Packages is promoted to the PROD view in my Artifact Feed.

Artifact Badges

As initial described, I love to visualize my artifacts, stages, and versions in my project documentation. For this I use badges.

All my team members see live information from CD automation like versions of my artifacts per stage. My visualisation in the “Readme.md” file is per example:

Additionally, I add such a table as MarkDown snippets to my Azure DevOps Dashboard.

Create Artifact Badges

To use this feature, you must be enabled “Package Badges” at the Artifact Feed configuration:

Afterwards, I can create a badges for each of my Artifacts by using the context menu in my Artifact Feed list:

The best of all, I can select each view. This allows me to visualize the current version of my Artifact at the respective staging environment.

In other words, I see that my “scm” app currently has version 1.0.4 in the “PROD” environment. How cool is this! 😛

Conclusion

First of all, my release management uses Azure DevOps Artifact Feeds to store all files for deployment as Packages. This is my central storage and starting point for my staging workflow.

In addition, I configure my Artifact Feeds and setup the Views similar to my stages. As result, I can promote each of my package versions to such a view.

Consequently, I add promotion tasks for each stage to my release pipeline. As result, I can track all successful deployments of certain artifacts in relation to the deployment stage.

In conclusion, my project documentation visualize my release management process. Therefore I use artifact badges to show the artifact version belonging to an environment.

What’s next?

Azure DevOps provide a lot of information. I’ll show you in my next post what information are available and how I offer more transparency to my project members.

In the meanwhile, I want your feedback! How do you manage your releases for Microsoft Dynamics 365 Business Central?

… Happy Sharing and don’t forget #NeverStopLearning