Skip to content

FEAT: Deployment automation for isolated GUI instances#1655

Open
varunj-msft wants to merge 2 commits intomicrosoft:mainfrom
varunj-msft:varunj-msft/8520-External-GUI-Deployment-Automation
Open

FEAT: Deployment automation for isolated GUI instances#1655
varunj-msft wants to merge 2 commits intomicrosoft:mainfrom
varunj-msft:varunj-msft/8520-External-GUI-Deployment-Automation

Conversation

@varunj-msft
Copy link
Copy Markdown
Contributor

Description

Adds deployment automation scripts and templates for spinning up isolated CoPyRIT GUI instances for external teams (CELA, model ops, partners).

New files:

infra/deploy_instance.py — Automates full instance deployment: resource group, Entra app registration + API scope + group claims, Azure SQL server + database, Key Vault + .env secret upload, Bicep deployment, SPA redirect URI, and RBAC role assignments. Includes --dry-run mode, KV name length validation, and retry with backoff for RBAC propagation.
infra/teardown_instance.py — Tears down an instance by deleting the resource group and optionally the Entra app registration.
infra/parameters.demo.json — Bicep parameter template for manual deployments.
infra/env.demo.template — .env template with all required and optional target env vars documented.
No changes to existing files. No Bicep or application code modifications.

Tests and Documentation

No unit tests — these are CLI deployment scripts that wrap az commands and are validated via --dry-run mode and mocked end-to-end flows. Deployment guide (infra/DEPLOY_NEW_INSTANCE.md) will follow in a subsequent PR.

No JupyText changes needed — no doc notebooks affected.

Comment thread infra/deploy_instance.py Outdated
Comment thread infra/deploy_instance.py
BICEP_TEMPLATE = INFRA_DIR / "main.bicep"


def run_az(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will say that on the surface it seem a little counter-intuitive to run the AZ CLI via Python. There's an underlying azure-sdk that we could call directly. You might have weighed pros and cons of that, of course.

The reason I'm not even really against it is that I joined a project that operated like this several years ago and it turned out to be pretty robust. That said, curious to hear your thoughts on the topic @varunj-msft

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so I went with az CLI because it was already a prerequisite in the README and the script directly automates the same manual az commands so it's easy to debug by running them individually. also avoids pulling in azure-mgmt-*/msgraph-sdk dependencies just for a deployment script. tradeoff is less type safety, but for an ops script that runs once per instance I think the simplicity wins

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants