Scenario: ALM at Scale¶
ALM is not a tool you deploy. It is a discipline you embed into how solutions are delivered.
TL;DR
ALM at scale requires: a defined solution structure (DIALOGE Go-Live), the right environment topology (SCALE-OPS Containment), automated pipelines (SCALE-OPS Automation), a lifecycle governance model (SCALE-OPS Lifecycle), and tier-appropriate enforcement (BOLT Tiers). Without all five, teams find workarounds — and workarounds become the de facto process.
Applies To
Audience: CoE Lead · Solution Architect · DevOps Engineer · Platform Admin Situation: Building repeatable, governed delivery pipelines for Power Platform solutions Frameworks: DIALOGE · SCALE-OPS · BOLT
The Situation¶
You have solutions in production. You have teams building more. The question is whether deployments happen through a governed, repeatable pipeline — or through ad-hoc export and import, personal connections, and "it works on my machine" promotions.
ALM at scale is the discipline of making the right way to deploy the easy way to deploy. This scenario defines how to get there.
The Sequence¶
Step 1 — Define the solution structure (DIALOGE: Go-Live)¶
Before pipelines, define what a well-formed solution looks like. Solutions that are not structured correctly cannot be promoted reliably — dependencies break, connections fail on import, and environment variables are missing.
Key decisions at this step:
- What goes in a solution? What stays out? (connection references, environment variables)
- Are solutions segmented by domain or delivered as monoliths?
- What is the branching and versioning strategy?
- What is the definition of "solution complete" before promotion?
Step 2 — Define the environment topology (SCALE-OPS: Containment)¶
The pipeline topology follows the environment structure. You cannot build a promotion pipeline without knowing what environments exist and what each one is for.
Standard topology:
Each boundary is a promotion gate. Each gate has defined criteria.
Key decisions at this step:
- How many promotion stages? (minimum: Dev → Test → Prod)
- Is UAT a separate environment or part of Test?
- Are environments Managed? (required for Pipelines feature)
- Who approves promotion at each gate?
→ SCALE-OPS: Containment · Environment Tier Decision Guide
Step 3 — Build the automated pipeline (SCALE-OPS: Automation)¶
With structure and topology defined, build the pipeline. Options range from Power Platform Pipelines (native, low-configuration) to Azure DevOps or GitHub Actions (full control, higher complexity).
Choosing the right pipeline tool:
| Situation | Recommended |
|---|---|
| Tier 1–2 solutions, makers not using Git | Power Platform Pipelines |
| Tier 3–4, engineering teams, Git required | Azure DevOps / GitHub Actions + Power Platform Build Tools |
| Mixed teams, varying complexity | Pipelines for Tier 1–2, DevOps for Tier 3–4 |
Key pipeline stages: 1. Export solution (unmanaged from Dev) 2. Run solution checker (quality gate) 3. Pack and version 4. Deploy to Test (managed) 5. Approval gate → Deploy to Production
Step 4 — Govern the lifecycle (SCALE-OPS: Lifecycle)¶
Pipelines handle promotion. Lifecycle governance handles what happens before and after: solution request, development tracking, deprecation, and retirement.
Key decisions at this step:
- How are new solution requests initiated and tracked?
- What is the deprecation process for solutions no longer needed?
- Who owns the solution inventory?
- How are breaking changes to shared components communicated?
Step 5 — Enforce by tier (BOLT: Tiers)¶
Not all solutions need the same ALM rigour. The BOLT tier determines the minimum ALM requirement:
| Tier | Minimum ALM Requirement |
|---|---|
| Tier 1 | No formal ALM required. Solution lives in maker workspace. |
| Tier 2 | Source control recommended. Managed deployment to business environment. |
| Tier 3 | Source control required. Automated pipeline. Code review before promotion. |
| Tier 4 | Full SDLC. Automated pipeline, automated testing, change advisory board approval. |
Common Mistakes¶
| Mistake | Consequence | How to Avoid |
|---|---|---|
| Pipelines built before environment structure is finalised | Pipeline topology changes mid-build | Define environment structure first |
| Connections not externalised as connection references | Connections break on import to new environment | Mandate connection references for all Tier 2+ solutions |
| No solution checker in pipeline | Quality issues reach production | Make solution checker a mandatory gate |
| Makers manually importing to production | Untracked changes, deployment errors | Block direct production access; require pipeline promotion |
| No deprecation process | Solution inventory grows indefinitely | Define lifecycle end-states from the start |