Project Status

Unreleased alpha that creates and deletes real Azure resources

The repository contains an installable PowerShell alpha. Beyond validating and planning, it authenticates to Azure, compares live resources, estimates live prices, deploys, probes, and tears down a lab.

None of it has been exercised against a live subscription and no release has been published, so nothing here is Available. Start-AzureDataLabDeployment creates real resources and Start-AzureDataLabTeardown deletes them.

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

Area	Status	Current scope
Architecture, documentation, pitch, and backlog	Current	Repository artifacts that can be read and built
Core and extension boundaries	Current and committed design	Current registries and contracts cover the SQL VM provider, networking, Key Vault, Bastion, Azure Files, catalogs, and one restore solution pack; future extension types remain committed design
PowerShell module and YAML schema	Current	Validation, deterministic SQL VM plans with desired resource properties and policy findings, metadata catalogs, support matrix, and JSON, Markdown, and HTML export
Azure sign-in and live resolution	Current	Connect-AzureDataLabAccount with process-scoped context, no autosave, and secure-string tokens
Azure-aware -WhatIf	Current	Test-AzureDataLabWhatIf reconciles a compiled plan against live state via native ARM WhatIf
Deployment, probes, and teardown	Current	Implemented and test-covered; never run against a live subscription and unreleased
SQL Server on Azure VM	Current	Fixed secure alpha plan, Azure reconciliation, deployment, probes, and approval-gated cleanup. Guest operations remain preview-first and user-executed
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

The design separates offline reasoning from live comparison, and both halves now exist. New-AzureDataLabPlan implements the offline plan contract: it explains resolved and derived values, ownership intent, actions, decisions, and unverified facts without Azure access. Test-AzureDataLabWhatIf implements the live half: it requires Azure context and reports create, reuse, update, replace, conflict, drift, or no-change without mutation.

Being implemented is not the same as being verified. Neither command has been run against a live subscription, so both stay Current rather than Available.

Delivery order

The order is deliberate. A later target should reuse tested Core behavior instead of creating a parallel toolkit.

1. SQL Server on Azure VM - read-only planning, secure canary, useful data lab, then first release.
2. Azure SQL Database and Azure SQL Managed Instance.
3. Azure Database for PostgreSQL, PostgreSQL on Azure VM, and containerized PostgreSQL.
4. Bicep, Terraform, and general Git and CI/CD adapters.
5. Microsoft Fabric - guidance and workspaces, then items and shortcuts, followed by parallel conditional CI/CD and solution-pack lanes.
6. 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

The committed design requires a secretStoreDecision for every target and solution pack and an administrativeAccessDecision for every Azure VM. The plan records these decisions, with Key Vault and Azure Bastion plus no VM public IP as defaults, and the deployment engine compiles them into the submitted ARM template. They have not yet been verified against a live subscription.

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

Use this order when sources differ:

1. Published releases and release notes define Available behavior.
2. The checked-in repository defines Current artifacts and verified development behavior.
3. Accepted architecture decisions define Committed design.
4. 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.