ALM & Lifecycle: LCS, Build Pipelines & Deployable Packages in Dynamics 365 Finance & Operations
Question 54 — Moving code from DEV to PROD safely with LCS, Azure DevOps and deployable packages.
Interview Question
Model Answer (Short)
ALM covers how customizations move from development to production reliably. Developers write code in a Tier-1 DEV box and check it into Azure DevOps (Team Foundation Version Control). A build environment / Azure Pipeline compiles the code, runs best-practice checks and produces a deployable package (a .zip of the compiled binaries). That package is uploaded to the LCS (Lifecycle Services) Asset Library and then deployed through LCS to the higher-tier Sandbox/UAT and finally PROD environments. Production deployments are Microsoft-managed and scheduled through LCS. This gives a controlled, auditable path: code → build → package → LCS → environments.
The ALM Building Blocks
LCS (Lifecycle Services)
- A cloud portal to manage projects, environments and deployments.
- Hosts the Asset Library where deployable packages are stored.
- Used to deploy packages to Sandbox/UAT and schedule PROD deployments.
- Provides monitoring, diagnostics and environment servicing.
Build pipeline & deployable package
- An Azure DevOps pipeline compiles the models from source control.
- The build produces a deployable package — a zipped set of compiled binaries.
- Best-practice checks can run as part of the build.
- The package is the single unit promoted across environments (never raw source).
Environment tiers
- Tier-1 (DEV/Build) — single-box dev and build environments (non-production).
- Tier-2+ (Sandbox/UAT) — multi-box, production-like, for testing.
- PROD — the live environment; deployments are Microsoft-managed via LCS.
Prerequisites (Rule 5)
- An LCS project with connected environments.
- Azure DevOps repository (TFVC) and a configured build pipeline.
- A Tier-1 build environment (or Microsoft-hosted build agent).
- Appropriate LCS roles to upload/deploy packages.
Example — Creating a deployable package (build tooling)
# Generate a deployable package from compiled metadata using ModelUtil / build tools
ModelUtil.exe -export ^
-metadatastorepath="I:\AosService\PackagesLocalDirectory" ^
-modelname="AbcCustomizations" ^
-outputpath="C:\Packages\AbcCustomizations.axmodel"
# The build pipeline then produces a deployable package (.zip)
# which is uploaded to the LCS Asset Library for deployment.Example — Azure DevOps pipeline stages (conceptual)
# Conceptual CI build stages for D365 F&O
stages:
- stage: Build
jobs:
- job: CompileAndPackage
steps:
- task: GetSource # pull from TFVC
- task: BuildXpp # compile models
- task: RunBestPractice # BP checks
- task: CreatePackage # produce deployable package (.zip)
- task: PublishArtifact # publish package artifactDeployment steps via LCS (conceptual)
# 1. Upload the deployable package to the LCS Asset Library
# 2. Select the target environment (UAT) in LCS
# 3. Apply the package -> environment goes into maintenance -> package installed
# 4. Validate in UAT, then schedule the same package to PROD (Microsoft-managed)Environment Tiers
| Tier | Type | Purpose | Deployment |
|---|---|---|---|
| Tier-1 | Single-box (DEV/Build) | Development & build | Manual / build agent |
| Tier-2+ | Multi-box (Sandbox/UAT) | Testing, production-like | Via LCS |
| PROD | Production | Live operations | Microsoft-managed via LCS |
Points the interviewer wants to hear
- Code flows DEV → Build → LCS → UAT → PROD.
- The build pipeline produces a deployable package (compiled binaries).
- LCS stores packages in the Asset Library and drives deployments.
- Only the package is promoted — never raw source code.
- PROD deployments are Microsoft-managed and scheduled in LCS.
Likely Follow-up Questions
- What is a deployable package and what does it contain?
- What is the difference between a Tier-1 and a Tier-2 environment?
- Why is only the package (not source) promoted across environments?
- How are production deployments handled differently?
Key Takeaway
D365 F&O ALM promotes a single deployable package along a controlled path: DEV check-in → Azure DevOps build → LCS Asset Library → UAT → PROD. LCS orchestrates deployments, and production is Microsoft-managed — giving an auditable, repeatable release process.