{"id":20018,"date":"2026-10-06T15:14:46","date_gmt":"2026-10-06T15:14:46","guid":{"rendered":"https:\/\/www.exam-labs.com\/blog\/?p=20018"},"modified":"2026-10-06T15:14:46","modified_gmt":"2026-10-06T15:14:46","slug":"microsoft-ai-103-ci-cd-for-foundry-projects","status":"publish","type":"post","link":"https:\/\/www.exam-labs.com\/blog\/microsoft-ai-103-ci-cd-for-foundry-projects","title":{"rendered":"Microsoft AI-103: CI\/CD for Foundry Projects"},"content":{"rendered":"

Microsoft Foundry now provides first-party CI\/CD patterns for hosted agents using Azure Developer CLI (azd<\/code>), GitHub Actions or Azure DevOps. Current guidance supports azd pipeline config<\/code>, GitHub OpenID Connect authentication, azd provision<\/code>\/azd deploy<\/code>, environment-specific Foundry projects, agent versioning, smoke tests and azd ai agent eval run<\/code> as a regression gate. Infrastructure can be managed with Bicep or Terraform while agent versions remain deployed through the Foundry\/azd lifecycle.<\/p>\n

Within Microsoft AI Agents<\/a>, CI\/CD should treat agent source, infrastructure, model deployment, configuration, tools, evaluations and production endpoint routing as one release system.<\/p>\n

Keep source and deployment configuration in Git<\/h3>\n

Store agent code, azure.yaml<\/code>, infrastructure templates, dependency manifests, eval configuration and pipeline files together.<\/p>\n

Do not make the Foundry portal the only source of truth for production settings.<\/p>\n

A deployment should be reproducible from a commit and environment configuration.<\/p>\n

Use azd for provisioning and deployment<\/h3>\n

Current Foundry guidance uses azd up<\/code> for first-time provision plus deploy, azd provision<\/code> for infrastructure and azd deploy<\/code> for agent code\/version deployment.<\/p>\n

This separation lets code releases avoid re-provisioning infrastructure unnecessarily.<\/p>\n

Pin the Foundry extension\/tool versions in CI where practical.<\/p>\n

Configure CI with federated identity<\/h3>\n

Current Microsoft templates use GitHub OIDC \/ federated credentials rather than long-lived Azure secrets.<\/p>\n

Assign only the roles the pipeline needs on the target Foundry project\/resource group.<\/p>\n

Keep application runtime identity separate from deployment-pipeline identity.<\/p>\n

Separate development, test and production projects<\/h3>\n

Current promotion guidance recommends distinct environment bindings rather than relying on environment names alone to isolate resources.<\/p>\n

Use separate Foundry projects\/resources where production isolation matters.<\/p>\n

Promote the same source revision through environments so failures are not mixed with code drift.<\/p>\n

Deploy code changes as new agent versions<\/h3>\n

Hosted agent deployments create versions.<\/p>\n

Previous versions can remain available for rollback or pinned endpoint routing.<\/p>\n

Do not overwrite the only production revision without a tested return path.<\/p>\n

Smoke-test every deployment<\/h3>\n

Microsoft’s current GitHub Actions quickstart deploys the hosted agent, reads status and invokes a safe test prompt.<\/p>\n

Add checks for expected output shape, tool availability and environment identity.<\/p>\n

A successful infrastructure deployment is not proof the agent can actually answer or call its dependencies.<\/p>\n

Run evals in CI<\/h3>\n

Current azd ai agent eval run<\/code> can run stored evaluation configuration in CI.<\/p>\n

Set release thresholds for important quality\/safety metrics and fail the pipeline when candidate behavior regresses.<\/p>\n

Keep eval datasets\/versioning independent from a deployment so a failing candidate cannot rewrite the test it is judged against.<\/p>\n

Manage infrastructure as code separately from agent versions<\/h3>\n

Foundry project initialization supports Bicep or Terraform infrastructure choices.<\/p>\n

Infrastructure state and agent version state are related but not identical.<\/p>\n

Use IaC for resource topology and azd deploy<\/code>\/Foundry agent lifecycle for application versions.<\/p>\n

Secrets should stay out of repository configuration<\/h3>\n

Store deployment variables and secrets in GitHub\/Azure DevOps secure stores or Azure-managed secret systems.<\/p>\n

Map them into azd<\/code> environments deliberately.<\/p>\n

Never commit model\/provider keys, MCP credentials or production connection secrets into azure.yaml<\/code>.<\/p>\n

Production rollout should be gradual<\/h3>\n

Current Microsoft guidance supports promoting hosted agent versions across environments and gradually routing production traffic.<\/p>\n

Canary the new version, monitor evaluations and runtime telemetry, then increase share.<\/p>\n

Keep the previous known-good version ready for fast route rollback.<\/p>\n

Foundry CI\/CD succeeds when the pipeline tests behavior, not just deployment<\/h3>\n

The mature pipeline provisions through IaC, authenticates with federated identity, deploys versioned agents, isolates environments, smoke-tests endpoints, runs eval gates, protects secrets and supports gradual promotion\/rollback.<\/p>\n

The release artifact is the behavior of the deployed agent plus its infrastructure and tools\u2014not merely a container or source ZIP.<\/p>\n

Pipeline design should separate CI from CD. Pull requests should run unit tests, linting, security scans and offline\/preview evals without touching production. Merges can deploy to a development or staging Foundry project, then promotion to production should require the appropriate quality\/security approvals for the application’s risk.<\/p>\n

Foundry project endpoint and environment variables should be explicit in every job. Current `azd ai` commands can resolve project context from flags, active azd environment, global config or environment variable. CI should set one deterministic source so a runner cannot accidentally target the developer’s default project.<\/p>\n

Infrastructure and agent code should have independent drift checks. Terraform\/Bicep can show whether Azure resources match desired state, while `azd ai agent show` can confirm the deployed agent version\/configuration. A project can be infrastructure-clean but still serve an unexpected agent version if endpoint routing changed manually.<\/p>\n

Production endpoints should be pinned during candidate deployment when necessary. Current hosted-agent deployment creates new versions and endpoint behavior can follow latest unless configured otherwise. Keep production pinned to the known-good version, deploy the candidate, evaluate it, then update routing deliberately.<\/p>\n

Pipeline smoke tests should exercise dependencies, not only return non-empty text. If the agent needs a search index, MCP server, Azure Function or database, include one safe test proving the integration is reachable with the deployed identity. This catches missing RBAC and secret\/config problems before users do.<\/p>\n

Eval thresholds should be versioned beside the eval configuration. A team can accidentally make a failing release pass by lowering the threshold in the same change. Protect critical eval configs with code-owner review and report baseline-versus-candidate metrics in the pipeline artifact.<\/p>\n

Secrets and model\/deployment names should be separated. Non-sensitive IDs\/endpoints can be GitHub Actions variables; credentials and API keys belong in secrets or managed identities. Prefer OIDC\/federated auth to long-lived service-principal secrets wherever supported.<\/p>\n

Environment promotion should reuse the same source revision but allow environment-specific infrastructure and model deployment names. Production may use a different region, SKU, private networking or model capacity. Keep these differences parameterized rather than forking the codebase.<\/p>\n

Rollback should be tested periodically. Re-route to the previous agent version, verify the endpoint, and ensure old dependencies\/secrets still work. A rollback plan that has never been exercised can fail because the previous version expects an index, connection or secret that was already removed.<\/p>\n

Pipeline observability should retain deployment logs, agent version, commit SHA, Foundry project, model deployment, eval results and smoke-test evidence. This gives incident responders a complete answer to ‘what changed?’ without reconstructing state from the portal.<\/p>\n

Foundry CI\/CD should keep generated cloud state out of the repository. Local `.azure` environment state and temporary credentials should not be committed. Store only declarative `azure.yaml`, IaC, workflow and source files, while CI reconstructs environment state from secure variables and cloud resources.<\/p>\n

Pipeline permissions should be split by stage where risk justifies it. A PR-validation identity may need no deployment rights; staging deployment may use one federated identity; production promotion may require a separate protected environment with reviewer approval. Least privilege reduces the blast radius of a compromised workflow.<\/p>\n

Source-code and container deployment modes should be chosen intentionally. Current Foundry supports direct source ZIP deployment for supported runtimes and container-based deployment for more control. The CI pipeline should test the exact mode used in production rather than a different local shortcut.<\/p>\n

Deployment artifacts should include dependency lockfiles and runtime version. Remote build is convenient, but reproducibility depends on resolving the same dependency set. Pin versions and review build logs so a package update does not change agent behavior without a source-code diff.<\/p>\n

Operational monitoring should continue after the pipeline turns green. Deployment success is the start of the observation window, not the end. Track agent errors, tool failures, latency, token\/cost, eval\/feedback signals and version-specific incidents during canary promotion.<\/p>\n

Use Agent Lifecycle Management<\/a> to define promotion ownership beyond the pipeline mechanics. CI\/CD can deploy quickly, but a governed release still needs an owner, risk classification, change record and rollback criteria.<\/p>\n

Model deployment changes should be isolated from agent source changes where possible. If the pipeline updates both code and the underlying model version simultaneously, a behavior regression is harder to diagnose. Promote the code against a pinned model first, then evaluate a model upgrade as a separate release.<\/p>\n

Quota and capacity checks should run before production rollout. A staging agent may pass smoke tests at low volume while the production model deployment lacks enough throughput for real traffic. Include a lightweight load or capacity validation step and monitor throttling during canary rollout.<\/p>\n

Use Azure OpenAI Model Versioning<\/a> as part of the deployment manifest so each hosted-agent version records the exact model deployment\/version it expects. This prevents a mutable shared model deployment from changing agent behavior outside the agent pipeline.<\/p>\n

CI\/CD itself should be monitored. Alert on repeated failed deployments, stale production versions, drift between main and deployed commit, failed eval gates and manual portal changes after deployment. A pipeline is only a control if teams can detect when production bypasses it.<\/p>\n

Release records should capture who approved promotion, the source commit, infrastructure revision, agent version, model deployment, eval suite version, smoke-test result and production routing change. This makes a Foundry incident traceable to one concrete release rather than a sequence of portal and pipeline events spread across several systems.<\/p>\n

Keep pipeline ownership and production promotion authority explicit so emergency changes remain auditable and reversible.<\/p>\n

Behavioral tests should cover prompt templates, retrieval quality, tool permissions, structured outputs, safety rules, and representative failure cases. A pipeline that only proves the infrastructure deployed successfully can still promote an application whose user-visible behavior regressed.<\/p>\n","protected":false},"excerpt":{"rendered":"

Microsoft Foundry now provides first-party CI\/CD patterns for hosted agents using Azure Developer CLI (azd), GitHub Actions or Azure DevOps. Current guidance supports azd pipeline config, GitHub OpenID Connect authentication, azd provision\/azd deploy, environment-specific Foundry projects, agent versioning, smoke tests and azd ai agent eval run as a regression gate. Infrastructure can be managed with […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-20018","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t