Catalogue › Copilot Code › code-deployment-readiness

Code deployment readiness

Checks that an AI-built application is ready to deploy and run - validated, security-reviewed, deployed through a pipeline to approved hosting, with least-privilege identity, monitoring, a rollback plan, a support route, named owners and recorded release approval for its risk tier. Use when an AI-built application is about to go live, when a prototype is being promoted, or when an application is running somewhere nobody approved.

Department

Copilot Code

Lifecycle

Assure, Launch

Maturity

builder, scaler, ai-enterprise

Risk tiers

1, 2, 3, 4

Platforms

copilot-code, github, azure, entra, power-platform

Editions

starter, scale, enterprise

Reviewers

security-privacy, evaluation-quality, design-authority

Status

draft

Copilot Cowork

Copilot Code plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

An application built quickly with an AI coding agent arrives at deployment with the same operational needs as any other software: somewhere approved to run, a repeatable way to deploy and roll back, monitoring, a support route and people who own it. The speed of the build often means these were never planned. This skill checks readiness to deploy and run an AI-built application against a proportionate checklist and records a go, conditional go or no-go. It goes wrong when "deployment" means the developer publishing from their machine to a resource they created, and the organisation learns the application exists when it fails.

When to use

• An AI-built application has passed validation and is about to go live.
• A prototype is being promoted into production use.
• An AI-built application is found running somewhere that was never approved.
• A significant release of a live AI-built application is planned.

When not to use

• Validating the application against its requirements - use copilot-code:application-validation.
• Security review of the generated code - use copilot-code:generated-code-security-review.
• Designing CI/CD pipelines for AI solutions, prompts and models - use ai-engineering:ai-ci-cd.
• Setting the organisation's release policy by risk tier - use platform-governance:ai-release-policy.
• Designing the ongoing support model for deployed AI solutions - use ai-operations:ai-support-model.

Questions to ask first

1. Has the application passed validation and security review, with no open blocking findings?
2. Where will it run, is that hosting approved, and who controls it?
3. How is it deployed: through a pipeline from the organisation's repository, or by hand?
4. How will anyone know it is failing, and how is it rolled back?
5. Who supports users, who fixes it, and who owns it as a business service?
6. Which release approvals does its risk tier require, and have they been given?

Required inputs

• The solution brief, validation verdict and security findings record.
• The organisation's approved hosting options, release policy and change process.
• The pipeline definition and environment configuration.
• Named business owner, engineering owner and support route.

If validation or security review is incomplete, the verdict is no-go. Never deploy to hosting the organisation has not approved, and never treat a developer's personal subscription or environment as production.

Decision framework

Check each area; the risk tier sets what is required.

Go when every required item is met; conditional go when only advisory items remain with owners and dates; no-go otherwise.

Practitioner approach

Start by confirming the evidence. The validation verdict and security findings record should exist and be current for the version being deployed. If the agent has made changes since validation, re-run the regression suite and check whether any change touched security-sensitive areas. Evidence for a previous version is not evidence for this one.

Confirm hosting is approved and owned. Many AI-built applications reach this point running in a developer's own environment, subscription or tenant area. Move them to approved, organisation-controlled hosting before go-live, even if that delays the date. An application on unapproved hosting has no guarantees about backup, security or continuity.

Make deployment repeatable. Deployment should run through a pipeline from the organisation's repository, so the version in production is always known and can be rebuilt. Manual changes in production are the main way AI-built applications drift from their reviewed code. From risk tier 2, add an approval step before production.

Check identity and secrets. The running application should use a managed identity or equivalent with only the permissions the brief requires, and any remaining secrets should live in a secrets store. Check what the identity can actually do, not what the design says.

Make failure visible and reversible. Confirm that errors and availability reach the engineering owner, and from tier 2 that alerts reach a support rota. Test the rollback: deploy the previous version to a test environment using the same pipeline. If the release includes data changes, decide how they would be reversed.

Confirm ownership and support in writing. The business owner answers for whether the application is still needed and used; the engineering owner answers for keeping it running and secure; the support route tells users where to go. Set a review date so the application is looked at again, and register it in the organisation's solution inventory.

Tell users. A short note on what the application does, what it does not, how to get help and how to report problems reduces support load and builds trust. Record the verdict and approvals, and hand over to operations.

Outputs

• A deployment readiness record: each area with status, evidence, owner and date, and a go, conditional go or no-go verdict.
• Recorded release approvals and reviewer sign-offs for the risk tier.
• A tested rollback procedure.
• An entry in the solution inventory with owners and review date.

Microsoft platform considerations

Hosting may be Azure services, Power Platform environments or other approved Microsoft platforms; each has its own environment, identity and governance controls, including Managed Environments for Power Platform. Use Microsoft Entra managed identities where available. Confirm current platform features, limits and governance options in the source records (ms-managed-environments) and with the platform team. Licensing and capacity questions go to the Microsoft licensing guide or a licensing partner.

Adoption considerations

Users need to know the application exists, what it is for and where to get help. Coordinate the go-live message with the business owner and, for wider audiences, with the adoption or change team.

Knowledge considerations

Not applicable as a primary concern, because readiness concerns running software; ensure the architecture note, runbook and brief are stored with the repository so support staff can find them.

Security and privacy considerations

No open blocking security findings, least-privilege identity, secrets in a store, approved hosting and environment separation are prerequisites. From risk tier 2, the security-privacy reviewer signs off access and exposure before go-live.

Responsible AI considerations

Where the application supports decisions about people or uses AI features at run time, confirm transparency to users and that human decision steps work in production as validated. Route outstanding concerns to responsible-ai:human-oversight.

Evaluation requirements

Validation evidence must match the version being deployed. From risk tier 2, the release evidence pack is reviewed through evaluation-quality:ai-release-evidence.

Value measures

Confirm the baseline and outcome measure from the brief, who will report it and when. Record deployment frequency and failed deployments at team level as operational health indicators. Never use deployment data to assess individuals.

Scale notes

Starter

Approved hosting, a simple pipeline, error visibility, a tested rollback, named owners and a support contact. A partner may host and support if no internal team can.

Scale

Provide standard hosting patterns, pipeline templates and a readiness checklist through the CoE or engineering platform team, and register every AI-built application.

Enterprise

Integrate readiness into the organisation's change and release management, with automated checks in pipelines and reviewer sign-offs recorded centrally from risk tier 2.

Hand-offs

• To ai-operations:ai-support-model for ongoing support.
• To platform-governance:ai-solution-inventory to register the application.
• To copilot-code:maintainability-review at the first scheduled review.

Reviewer gates

From risk tier 2, security-privacy signs off access and exposure, evaluation-quality:ai-release-evidence reviews release evidence, and design-authority reviews supportability through design-authority:supportability-review. Findings are blocking or advisory; go-live does not proceed with an open blocking finding.

Failure modes

• The application goes live from a developer's own environment, and nobody can rebuild it when that person leaves.
• Manual changes in production drift from the reviewed code.
• Nobody is alerted when it fails, and users discover it first.
• Validation evidence is for an earlier version than the one deployed.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Deploy to hosting the organisation has not approved or does not control.
• Go live with an open blocking security finding and no written risk acceptance.
• Deploy without named business and engineering owners and a support route.
• State licensing or capacity conclusions; route them to the Microsoft licensing guide or a licensing partner.