Operations

---

title: Deployment and Operations description: The current release path, identity prerequisites, and how to inspect a release. Author-only; nothing here has been dispatched.

Release path

hosted-agent-cd.yml is a thin workflow_dispatch-only wrapper that calls the reusable deploy-and-evaluate.yml workflow with secrets: inherit. Neither entry point fires automatically; both require a manual dispatch, and both carry the same "author-only, do not dispatch until Gates G2/G3/G6 clear" banner described in Home and Workflows.

flowchart TD
  Dispatch[Manual dispatch] --> Lint[Lint and offline unit tests]
  Lint --> Bicep[Bicep build and what-if against staging]
  Bicep --> Images[Build MCP images with az acr build; resolve digests]
  Images --> Stage[azd provision and azd deploy to staging]
  Stage --> Eval[Deterministic evaluation gate]
  Eval --> Approval[Production environment approval]
  Approval --> Prod[azd provision and azd deploy evaluated digests to production]

Loading

Production receives a remote rebuild of the exact evaluated agent source, and the exact digest-pinned MCP images built during the staging stage; it is not a copy of a running staging container. Promotion happens in the promote-production job, which targets the production GitHub Environment: repository-configured required reviewers gate that job from starting, which is the manual production-approval step. There is no dedicated approval job beyond that environment protection.

Unlike the sibling foundry-hosted-agents repository, this repository's evaluation gate (eval/evaluation_gate.py) is fully deterministic and local: it re-runs the golden dataset against the calculator, approval repository, and agent graph code that was just packaged and deployed. It does not call an LLM judge or a live agent endpoint, and there is no Responses-protocol smoke test, because src/quote-preparation-agent/main.py is a local-only entry point, not a hosted server.

Identity and environment prerequisites

Every job that talks to Azure uses secretless OIDC login (azure/login@v3 with client-id/tenant-id/subscription-id repository variables, no stored secret). See Workflows for the full list of required repository variables and the RBAC roles the CI identity needs.

Immutable MCP image promotion

The staging stage builds both application-server and rulebook-server images with az acr build, tagged ${GITHUB_SHA}-${GITHUB_RUN_ID}-${GITHUB_RUN_ATTEMPT}, then resolves each image's SHA-256 digest and stores it as an azd environment variable. The production stage refuses to provision unless both APPLICATION_MCP_IMAGE and RULEBOOK_MCP_IMAGE end in a valid @sha256:... digest, so production always runs the exact images the deterministic evaluation gate ran against, never a floating tag.

Inspect a release

gh run view <run-id> --repo devopsabcs-engineering/foundry-hosted-agents-fsi
gh run download <run-id> --repo devopsabcs-engineering/foundry-hosted-agents-fsi -n evaluation-evidence-1

Use a new output directory when downloading another run. eval/results.json (uploaded as evaluation-evidence-<attempt>) contains the full per-record deterministic check report described in Release Evidence.

Repeat execution

azd provision targets existing named resources and role assignments, so re-running it is idempotent. A release still creates a new immutable agent version and a new build record each time; it is not a no-op deployment.