grok14ENGINEERING FIELD SCHOOL
Curriculum/Module 13
Ship / Week 13

CI/CD & LLMOps

Version the whole AI application and release only when the relevant engineering and evaluation gates pass.

5 lesson sections16-hour study & practice planModule 12 or equivalent experience

See the system

Version the whole AI application and release only when the relevant engineering and evaluation gates pass.

Version all behavior-changing components, run the relevant checks, verify staging, promote the tested artifact, and observe with an established rollback path.
A repeatable release path. Version all behavior-changing components, run the relevant checks, verify staging, promote the tested artifact, and observe with an established rollback path.
Module 13 / Lesson 01

Define the release unit

An AI release includes more than source code. Prompt templates, model configuration, dependencies, tool contracts, retrieval settings, and evaluation data can all change behavior. Record their versions together.

A release manifest links these components to the tested artifact. Avoid rebuilding from an unpinned branch after approval. The code deployed should be the code reviewed and evaluated, with environment differences explicit.

Apply the ideaCreate a release manifest for the support copilot with version identifiers for each component.
Module 13 / Lesson 02

Layer checks by cost and signal

Run fast deterministic tests on routine changes. Add integration and managed-platform checks where the affected boundary requires them. Expensive live-model evaluations should have explicit triggers and budgets, not run accidentally for every trivial edit.

Use fixtures for reproducible failure tests, and record which checks used a live provider. A passing mock adapter test does not demonstrate that the real provider contract still works.

Apply the ideaDefine pull-request checks and a separate pre-release managed verification stage.
Module 13 / Lesson 03

Deploy resources from versioned configuration

Declarative Automation Bundles, formerly Asset Bundles, let Databricks project resources and source configuration participate in source control and deployment workflows. Learn the validate/deploy/run lifecycle using current official documentation.

Keep environment-specific identities and parameters explicit. Never commit secrets. Validate against the target environment and handle existing resources deliberately rather than overwriting an unknown workspace.

Apply the ideaSketch development and production target differences without adding credentials.
Module 13 / Lesson 04

Promote with evidence

Promotion should depend on code checks, evaluation results, permissions, operational readiness, and the applicable release policy. An aggregate quality improvement cannot hide a critical security regression. Record who owns the go/no-go decision.

A canary limits exposure while observing real behavior, but requires a defined cohort, signals, and stop condition. Randomly sending a fraction of traffic to a candidate without a response plan is not a complete rollout strategy.

Apply the ideaWrite a rollout plan with success signals and a rollback trigger.
Module 13 / Lesson 05

Rehearse rollback and compatibility

Rollback can fail if the old application cannot read a new schema or if an irreversible tool action already occurred. Plan compatibility and data migrations separately from swapping code versions.

Rehearse restoring the previous tested configuration and verifying the critical user path. Preserve evidence of the failed release for diagnosis while protecting sensitive data. Document which effects rollback can and cannot reverse.

Apply the ideaExplain how a prompt rollback differs from undoing a ticket update already sent to an external system.

Worked scenario

A prompt change starts proposing unsupported ticket states. Schema tests catch the invalid category locally; held-out task evaluation finds additional behavior regressions. The release remains blocked. Fix and reevaluate the same candidate artifacts instead of editing the deployed prompt manually.

Practical assignment

This is a practical design or implementation assignment. Use synthetic data. Where managed services are required, verify account access, costs, supported features, and cleanup before provisioning.
  1. Run the bundled deterministic checks.
  2. Create a release manifest.
  3. Design CI stages with explicit live-test budgets.
  4. Introduce a deliberate contract regression and verify failure.
  5. Document a deployment/promotion path.
  6. Rehearse a local rollback and state which managed steps remain unverified.

What to submit

Submit the artifacts named above, a short explanation of your decisions, and evidence of the checks you performed. Distinguish measured results from estimates and designs from executed integrations.

Review dimensionSubmission evidence
CorrectnessShow the expected behavior and a meaningful counterexample.
ReproducibilityState setup, inputs, versions, and what was actually executed.
Delivery judgmentExplain the client impact, alternative, and unresolved assumption.
Operational boundaryIdentify permissions, failure behavior, and any resource cleanup.
Open the lab workbenchGet delivery templates

Knowledge check

1. What belongs in an AI release manifest?
2. What does a mock test prove?
3. Can rollback undo every external side effect?

Answer guide
  1. Code, prompts, configuration, dependencies, and evaluation versions. Many independently changing components affect application behavior.
  2. Behavior against the mock’s contract. Live integrations require their own appropriate verification.
  3. No. Completed business actions may require separate compensating procedures.

References & next step

Platform examples are environment-dependent. Start with the official documentation in the reference library and verify the exact cloud, region, privileges, and versions you use.

Open the official reference library

Editorial edition: 5 October 2026. The local reference lab is executed locally; this course does not claim a live Databricks deployment.