Project Status
Status labels
Section titled “Status labels”| Status | Meaning |
|---|---|
| Current | Verified repository or release behavior that exists now. Current does not necessarily mean deployable. |
| Committed design | An accepted architecture decision that is not yet implemented. |
| Backlog | Intended work whose implementation contract is not settled. |
| Exploratory | Research or an unresolved design question; it is not a promise. |
| Deferred | Work explicitly postponed to a later phase. |
| Available | Released, documented, and verified functionality. This label is reserved for release behavior. |
No deployment capability is currently marked Available.
Current repository truth
Section titled “Current repository truth”| Area | Status | Current scope |
|---|---|---|
| Architecture, documentation, pitch, and backlog | Current | Repository artifacts that can be read and built |
| Core and extension boundaries | Committed design | Accepted separation of target providers, capability modules, catalog sources, solution packs, deployment engines, and probes |
PowerShell module, YAML schema, -Plan, and -WhatIf |
Backlog | No installable module or command implementation exists |
| SQL Server on Azure VM | Backlog | First end-to-end implementation and proof point |
| PostgreSQL managed, VM, and container paths | Backlog | Three separate pre-Fabric delivery segments |
| Bicep and Terraform engines | Backlog | Scheduled after stable target paths and before Fabric; neither is implemented |
| General Git and CI/CD adapters | Backlog | GitHub reference plus Azure DevOps, GitLab, Gitea, and Forgejo before Fabric |
| Fabric infrastructure as code | Exploratory | Practical API and engine boundaries remain under research |
| Kubernetes targets | Deferred | Begin only after container contracts and a required workload are released |
Plan and WhatIf
Section titled “Plan and WhatIf”The committed design separates offline reasoning from live comparison. -Plan will validate configuration and explain resolved and derived values without Azure access. -WhatIf will require Azure context, compare that resolved plan with existing resources, and report create, reuse, update, replace, conflict, drift, or no-change without mutation. Neither command is implemented today.
Delivery order
Section titled “Delivery order”The order is deliberate. A later target should reuse tested Core behavior instead of creating a parallel toolkit.
- SQL Server on Azure VM - read-only planning, secure canary, useful data lab, then first release.
- Azure SQL Database and Azure SQL Managed Instance.
- Azure Database for PostgreSQL, PostgreSQL on Azure VM, and containerized PostgreSQL.
- Bicep, Terraform, and general Git and CI/CD adapters.
- Microsoft Fabric - guidance and workspaces, then items and shortcuts, followed by parallel conditional CI/CD and solution-pack lanes.
- Azure Databricks, later data providers, SQL Server on Linux or containers, and eventually Kubernetes.
The exact S0-S22 sequence and gates are in the Roadmap. Delivery order is not a technical dependency: Terraform does not technically depend on Bicep, and Fabric workspace creation does not technically depend on Git.
Cross-segment work is represented by child issues. This keeps the S4 interactive VM canary on protected local state while remote locking, fencing, and unattended resume remain release work for S6.
Required security decisions
Section titled “Required security decisions”The committed design requires a secretStoreDecision for every target and
solution pack and an administrativeAccessDecision for every Azure VM. Key
Vault is considered explicitly for every solution; Azure Bastion with no public
IP is the default for VMs. These are contracts, not implemented controls today.
First implementation proof
Section titled “First implementation proof”SQL Server on Azure VM must prove one complete path: YAML validation, -Plan,
-WhatIf, cost review, explicit Key Vault and Bastion decisions, guarded
PowerShell deployment, probes, evidence output, teardown preview, confirmed
deletion, and cleanup proof.
Source of truth
Section titled “Source of truth”Use this order when sources differ:
- Published releases and release notes define Available behavior.
- The checked-in repository defines Current artifacts and verified development behavior.
- Accepted architecture decisions define Committed design.
FEATURE_REQUESTS.md, issues, and the project board describe Backlog, Exploratory, and Deferred work.
The architecture is not proof of implementation, and the roadmap is not a delivery commitment. Azure SQLVM Toolkit is an unfinished predecessor; its features do not transfer automatically to this repository.