CI/CD for Models and Prompts

In an LLM application, a one-line change to a prompt can alter behaviour as much as a code change, and a model upgrade can alter it more. Yet prompts are often edited in a dashboard and models swapped by changing an environment variable, with no tests and no way back. The same CI/CD practices that make code changes safe work for models and prompts, with one addition: evaluation.

Version everything that changes behaviour

Before you can test or roll back, you need to know exactly what is running. Treat these as versioned artifacts:

• Prompts and templates, stored in Git next to the code that uses them, or in a prompt registry that records versions.
• Model identifiers, pinned to an exact version or snapshot for hosted APIs and an exact revision or file hash for open models.
• Generation settings such as temperature, maximum tokens and stop sequences.
• Retrieval configuration for RAG: embedding model, chunking settings, index version.
• Fine-tuned weights and adapters, stored in a model registry (MLflow, a Hugging Face Hub private repository, or object storage with clear naming) with the dataset and training run that produced them.

Record all of these versions in logs and traces for every request, so you can tie any output back to the configuration that produced it.

Evaluation is the test suite

Unit tests still matter for the code around the model, but behaviour needs evaluation. Keep a dataset of real inputs with expected outputs or grading criteria, in version control, and grow it every time you find a failure in production.

Checks typically include:

Check type	Example
Deterministic	Output parses as valid JSON; required fields present; length within limits
Reference based	Extracted values match the expected ones; classification label correct
Model graded	An LLM judge scores relevance or faithfulness against the source
Operational	Latency and token cost per case within budget

Tools such as promptfoo, DeepEval and the evaluation features in Langfuse or MLflow run these in a pipeline. Model graded checks vary from run to run, so compare against a baseline with a tolerance, rather than demanding an exact score.

Gates in the pipeline

A practical pipeline for a prompt or model change:

1. On pull request: run fast deterministic checks and a small evaluation subset. Post the score difference against main as a comment so reviewers see the effect.
2. On merge: run the full evaluation set. Block the release if any key metric falls below the accepted baseline.
3. Before production: deploy to staging and run a smoke test against the real serving stack, including the inference server or provider API.

Evaluation runs cost tokens or GPU time. Keep the pull request subset small and representative, and run the full set where it matters.

Release gradually

Offline evaluation cannot cover every real input. Roll out in steps:

• Shadow mode: send a copy of live traffic to the new version without showing its output to users, and compare results.
• Canary: route a small share of traffic to the new version, watch quality signals, errors, latency and cost, then increase. On Kubernetes, Argo Rollouts or Flagger can automate the progression, or a gateway can split traffic by weight.
• Feature flags: switch prompts or models per customer or per feature without a redeploy.

Define in advance what metrics will stop a rollout, and automate the stop if you can.

Make rollback boring

Because every prompt, model and setting is versioned, rollback means pointing back to the previous version. Test that it works before you need it. For self-hosted models, keep the previous model version deployable, with its weights still available and its image still in the registry. For hosted APIs, remember that providers retire older model versions on their own schedule, so plan migrations before an old version disappears.

Watch after release

Production data feeds the loop. Monitor the same signals you evaluated offline, sample outputs for review, and add new failure cases to the evaluation set. Over time that dataset becomes your most valuable asset for every future change.

DoneDeploy builds CI/CD pipelines in GitHub Actions, GitLab CI and Argo CD, and extends them with evaluation gates and progressive delivery for LLM features. If prompt and model changes feel risky in your team, get in touch.