Setup of a modern Development Process for Microsoft Dynamics 365 Business Central with Azure DevOps is state of the art. It’s future proof, especially to handle monthly updates in the SaaS world.

Unfortunately, there is no standard setup for Azure DevOps and no standard CI / CD process available – not yet.

Conclusion – we need to define this Setup and the CI / CD process for MSDyn365BC!

Artifacts

Let’s keep it simple – an Azure DevOps Artifact is a package. It contains the App (in my case also the Test-App) for Business Central and sometimes “Data” as Rapid Start Packages. If you can’t avoid Hybrid Development for OnPrem, than the Artifact contains also the FOB-File.

An Artifact is unchangeable – NEVER change the content! Regenerate instead a new Artifact version by triggering the CI pipeline.

During deployment process the Artifact (App & FOB) will be installed at testing and production environments.

Deployment Stages

D-Stage is closest to the development and contains latest generated Artifacts (e.g. from [dev] or [release] Branch). The database is mostly a test database based on CRONUS company. I prefer this stage to setup the time triggered (nightly) test automation.

Q-Stage is used for Quality Assurance. This stage is more stable than the D-Stage and the database can be used for manual setup for test data. This stage is preferred by consultants to prepare database setups, Rapid Start packages, and to run additional integration tests. When this stage is succeeded, the Artifact is shipped to the customer environment.

UAT-Stage (User Acceptance Test) is used to approve the correctness of the deliverable by customer and it’s Key-Users. This stage is based on a copy of the production database – in Business Central SaaS you can use a “Sandbox”. This environment is often used to prepare and run End-User workshops with related company data.

P-Stage is the goal for each deployment. If the Artifact survives all other stages, it will be deployed to the Live-System of the customer – the production tenant. This is the point-of-no-return. If you skipped testing in previous stages and something corrupt your production data… In this case a good Backup Strategy may help…

What’s next

I’ll continue soon… With my version of the Artifact Flow in the deployment process.

I like to read your comments, suggestions, and be curious if you use other approaches or stages.