CI/CD, Quality Gates, and AI Release Gates

A delivery pipeline turns one reviewed commit into one traceable artifact, proves required properties, promotes the same artifact through environments, migrates data safely, deploys gradually, verifies production health and AI quality, and rolls back quickly. CI credentials must be short-lived and least-privileged because the pipeline is part of the production trust boundary.

What will you be able to do?

• design fast feedback and deeper release stages;
• secure CI with workload identity and protected environments;
• gate code, schema, contracts, supply chain, and AI behavior;
• canary and roll back application, prompt, model, and index versions.

What should the pipeline prove?

Pull request stage

• formatting, lint, static types, unit/property tests;
• integration tests with PostgreSQL/Redis where relevant;
• OpenAPI/event/schema compatibility diff;
• migration lint plus fresh-install and upgrade test;
• dependency, secret, SAST, container/IaC scans;
• fast deterministic AI evaluations and hard safety invariants.

Release stage

• reproducible image built once, signed/attested where supported, SBOM attached;
• full integration, provider contract smoke, and representative evaluation suite;
• migration rehearsed on production-shaped data;
• artifact promoted by digest, never rebuilt per environment.

Deployment stage

• environment approval and short-lived workload identity;
• expand migration, compatible app canary, health/SLO/evaluation comparison;
• gradual traffic increase, automated abort, rollback verification;
• later contract migration after old versions are gone.

How do AI changes ship?

Prompt, output schema, routing policy, model alias, retrieval index, safety policy, and evaluation dataset are versioned release inputs. Some can change through configuration without a new container, but they still require review, evaluation, canary, audit, and rollback. Record the exact version set for every AI run.

How should CI secrets work?

Prefer CI-to-cloud federation that issues short-lived, audience-bound credentials. Protect release environments, pin or review third-party actions, minimize repository token permissions, isolate untrusted pull requests, and prevent fork code from accessing secrets. Store no long-lived production key in source or ordinary CI variables if a workload identity exists.

Why does this matter in AI-native systems?

A provider can release a new model behind a name or deprecate behavior independently. Use controlled aliases, explicit qualification, and drift monitoring. Quality regressions need the same automated stop authority as HTTP error regressions.

Common mistakes

• Building a different image for staging and production.
• CI runs untrusted code with deployment credentials.
• Migrations execute in every replica.
• AI evaluation is manual and skipped under release pressure.
• Rollback app version cannot read the expanded schema.
• Provider/model configuration changes have no audit trail.

AI Pair-Programmer Prompt

Exercise

Write a pipeline specification for adding a ticket category column and changing the classification prompt/model. Include a deliberately regressing candidate.

Acceptance criteria: the regression cannot promote, the same image digest reaches production, migration stays compatible during canary, and app plus AI versions can roll back independently.

Knowledge check

1. Why build an artifact once?
2. Are prompt-only changes exempt from release gates?
3. Why isolate untrusted pull requests?

---

Answers

1. Promotion then refers to the exact tested bytes, reducing environment drift.
2. No; they change product behavior.
3. They can execute attacker-controlled code and must not receive secrets or deployment authority.

Completion checklist

• Code, data, contracts, supply chain, and AI behavior are gated.
• Credentials are short-lived and scoped.
• Canary abort and rollback are rehearsed.

Primary references

• GitHub Actions security
• SLSA
• OpenSSF Scorecard