ALM & CI/CD best practices, end to end: a Dynamics 365 Customer Engagement walkthrough

Summary of the article published on LinkedIn. “View original” opens the full text.

Why ALM matters even more in Dynamics 365

In most projects, source code is the single source of truth. In Dynamics 365 it is a mix of code (plugins, PCF, web resources), metadata (tables, forms, views) and configuration (connection references, environment variables, flows), all bundled inside a solution. Get the process wrong and you don’t just get a broken build; you get a broken tenant.

The building blocks

• Environments: Development → Build/Integration → Test/UAT → Production. Only the pipeline deploys to UAT and Production, with an automatic pre-deployment backup.
• Obfuscated data: when Dev or Test is refreshed from Production, personal data is masked before anyone gets access (GDPR).
• Branching: trunk-based with release branches; feature/* per story, hotfix/* for urgent fixes. Branch policies require a passing build, reviewers and a linked work item.
• Traceability: user story → branch → PR → build → release → Production, linked by the work item ID, with a Definition of Ready and a Definition of Done.
• Pull requests: technical and functional review, Solution Checker and a secret scanner as required checks.
• Unpacked solution in source control (pac solution unpack): unmanaged in Dev, managed everywhere else.
• Pipelines: CI validates the build and Solution Checker on every PR; CD promotes through stages with approvals and injects environment variables and connection references per stage, never hand-edited.

The checklist

Rollback plan, secrets management and post-deployment monitoring are defined before go-live, not improvised during an incident.