Deployment Engines
A deployment engine translates an approved normalized plan into engine-specific artifacts and applies supported actions through core orchestration. Target providers describe intent; engines own export and apply syntax.
| Engine | Status | Long-term role |
|---|---|---|
| PowerShell | Committed design, first | Export an auditable action package and apply supported actions |
| Bicep | Backlog, S12 | Export Azure-native templates and apply them through orchestration |
| Terraform | Backlog, S13 | Export configuration and apply it through orchestration with an explicit state boundary |
The engine is selected explicitly. The core never guesses from installed tools or configuration files.
Engine contract
Section titled “Engine contract”An engine must:
- declare its adapter and tool versions;
- publish supported plan-node and capability versions;
- export deterministic artifacts from the approved plan;
- preserve stable plan IDs in generated artifacts and evidence;
- preview and apply without changing target-provider meaning;
- return structured outputs, diagnostics, and partial-failure evidence;
- expose engine-native state identifiers without treating them as toolkit state;
- refuse unsupported capabilities before mutation.
The exported package contains a manifest tied to the plan hash. Manual edits break that binding and require re-planning or an explicit import workflow; the toolkit does not silently apply modified output as the approved plan.
Export and apply
Section titled “Export and apply”Bicep and Terraform are both intended to support export and apply. Apply is still coordinated by the toolkit so approvals, idempotency, evidence, probes, and cleanup rules remain consistent.
Engine-native preview evidence may supplement toolkit -WhatIf:
- PowerShell may show command-level previews;
- Bicep may attach an Azure deployment what-if result;
- Terraform may attach a saved plan summary.
Those previews do not redefine -WhatIf. Toolkit -WhatIf always reconciles the
normalized plan with live Azure state and uses the common
create/reuse/update/replace/conflict/drift/no-change vocabulary.
State boundaries
Section titled “State boundaries”Toolkit run state records orchestration, ownership, approvals, stable IDs, events, and evidence. An engine may keep its own deployment state:
- PowerShell records action receipts but has no separate desired-state store.
- Azure Resource Manager keeps deployment history for Bicep.
- Terraform keeps engine-native state in a configured backend.
The run state stores only references, versions, and hashes for engine-native state. It does not copy credentials or secret values. Reconciliation must compare the toolkit plan, toolkit run state, engine state where applicable, and live resources before resume or teardown.
Parity
Section titled “Parity”Parity is capability-based, not all-or-nothing. A support matrix identifies each
provider capability as preview, export, apply, probe, and teardown for
each engine. Missing support is a structured capability failure.
PowerShell must be implemented and proven first. Bicep and Terraform work starts only after the normalized plan, provider, evidence, and state contracts are stable. They are scheduled after the initial SQL, PostgreSQL VM, and containerized PostgreSQL delivery paths and before Fabric.
Terraform does not depend technically on Bicep. Their S12/S13 order limits parallel delivery risk and gives each engine an independent conformance gate. Neither engine’s earlier delivery implies complete Fabric infrastructure-as-code support; Fabric exposes only operations its provider and current APIs can reliably plan, execute, and evidence.