Technical enablement · 06

Deployment models

How {{product.name}} is built, shipped and run today on Azure Container Apps, how releases flow from GitHub Actions, which environment variables it needs (names only), and what a dedicated deployment would involve.

The two models at a glance

Comparison

Model A — the Azure Container Apps instance

Runtime topology

Environment variables

Names only. The values live in a local .env (never committed) and, once deployed, as Container App secrets. .env.sample in the repository lists the same names.

Make targets

The Makefile reads .env and wraps the Azure CLI. Defaults can be overridden on the command line.

CI/CD with GitHub Actions

Two workflows in .github/workflows/.

• Sign-in by OIDC federation. The deploy job signs in to Azure with a federated token, so no client secret is stored in GitHub. The federated credential is bound to the production environment, not to a branch. The GitHub secrets hold identifiers only (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID).
• Least privilege. The pipeline identity can push an image and roll a revision on the two named resources. It cannot widen its own access.
• App secrets stay out of GitHub. They already live on the Container App and survive an image update. To add or rotate one, run make deploy from a machine holding .env.
• Gating. Add required reviewers to the production environment to make deployment an approval step rather than automatic.
• Smoke check. The pipeline polls the sign-in page for a 200 for up to two minutes.

Rollback

Deploy the previous image tag. Find tags in the registry and the running revision in the Container App.

make deploy TAG=<previous-tag>

# or directly:
az containerapp update --name ca-ai-yield --resource-group <RESOURCE_GROUP> \
  --image <REGISTRY>/ai-yield:<previous-tag>

Database changes do not roll back with the image. Additive migrations are safe to leave in place; see migrations for the ordering rule.

Model B — dedicated deployment

The build brief intends a dedicated deployment to be a configuration of the same codebase, used where a regulated client needs isolation or a specific data region. No dedicated instance has been built, and no infrastructure-as-code for one exists in the repository. Working assumption, not a decision: the same image on Azure Container Apps in the client's declared region, run by the product team. No owner or decision date has been set; the decision belongs with the service owner, Legal and the Data Privacy Officer. The AWS work is a separate track for a second instance, not a dedicated client stack.

Prerequisites a dedicated stack would need

• PostgreSQL and Redis in the client's declared region, with the application in the same region.
• A container platform able to run the image and a Container Apps Job equivalent (or any scheduler that can call the three job routes with the x-cron-secret header).
• Its own LiteLLM gateway, with a callback secret shared with the app.
• An Entra ID app registration, or an agreed alternative sign-in route. Client-user sign-in is not designed beyond Entra ID today. The brief mentions per-tenant identity providers or email one-time codes, neither of which is built. Proposed first step: invite client users as guests to the product's Entra directory, which needs no code change; to be confirmed.
• A named technical owner and an agreed change window.

Which model to choose