Does continuous mean the system is deploying every second?

No. It describes an ongoing practice of integration and release readiness or automation, not a literal uninterrupted deployment stream.

Can a delivery pipeline include human review?

Yes. Continuous delivery can keep releases ready while retaining a release decision or other appropriate review stages.

Is retraining automatically continuous deployment?

No. Producing a new model and releasing it to users are separate operations with separate checks.

AI Glossary / Data engineering and architecture / Beginner

CICD or CI/CD

Definition

CI/CD means continuous integration combined with continuous delivery or continuous deployment. It describes practices and automated workflows for integrating changes, checking them and preparing or releasing software repeatedly. The two meanings of CD differ: delivery keeps changes ready for release, while deployment automatically releases qualifying changes through the defined process.

What it means

Continuous integration encourages developers to combine work frequently and obtain prompt feedback from builds and tests. This helps expose incompatible changes before a large collection of unfinished work accumulates.

Continuous delivery extends the process so a tested version can be released reliably when the organization chooses. Continuous deployment goes further by making the production deployment automatic once the required conditions are met. A team should state which meaning it intends instead of assuming that CD has only one interpretation.

The practice is broader than owning an automation tool. A pipeline that runs tests on rarely integrated branches does not, by itself, establish frequent integration or a reliably releasable product.

How it works

A change enters version control and triggers relevant checks. Early stages commonly build the software and run fast tests. Later stages can examine integration behavior, package a versioned artifact and exercise it in an appropriate environment.

A delivery workflow records which artifact passed which checks and how it moves toward release. Depending on policy, a production stage may require approval or may proceed automatically. These are workflow choices, not a universal requirement that every team deploy every commit.

After deployment, monitoring checks the real service. A release process should include a practical response to failure, such as reverting an application version or moving forward with a correction. Database and data changes can make rollback more complicated than replacing a program file.

For AI applications, the released system may depend on code, model files, prompts, retrieval configuration and data transformations. Tests should assess the relevant behavior, and versions should identify what was actually evaluated. A passing build does not establish that model quality is acceptable.

Three practical examples

A website runs its tests when a proposed change is submitted and builds a versioned release after review and integration.
A data engineering team checks transformation logic and schema expectations before deploying an updated scheduled pipeline.
An AI service evaluates a new prompt or model against an agreed test set before promoting the resulting application configuration.

Think of it this way

Think of a repeatable inspection route through a workshop: components are assembled, checked and prepared for shipment using recorded steps. Delivery means an inspected product is ready to ship; deployment adds automatic shipment when the defined conditions are satisfied.

The analogy has limits. Software can change after release through data and configuration, and no inspection covers every future situation. The pipeline creates evidence and repeatability; it does not guarantee that an untested scenario can never fail.

Worked example

An assistant release gate

Consider an invented assistant release with three required checks: all 80 deterministic software tests must pass, at least 46 of 50 defined answer-quality cases must meet the review criteria, and all 12 access-control cases must pass. These are illustrative thresholds.

A candidate passes the 80 software tests and scores 48 on answer quality, but fails one access-control case. It does not qualify for promotion under the stated policy, even though its average-looking quality score is high.

After correction, the team reruns the affected evaluation and required release checks on the exact candidate version. It records the model, prompt, retrieval settings and evaluation version associated with the artifact.

In a delivery workflow, the resulting candidate can await a release decision. In a deployment workflow, it can proceed automatically if all configured conditions are satisfied. Neither approach should quietly ignore a required failure because other checks passed.

Illustrative case study

A fictional analytics team has a pipeline that tests its code but deploys an unversioned model file named latest. The file changes between evaluation and production deployment, so the deployed behavior does not match the evaluated candidate.

The team gives the model an immutable version reference and records it with the application artifact. It also versions the relevant preprocessing configuration and validates that the same combination is used in the target environment.

Release traceability matters. Automating the steps is not enough when those steps refer to changing inputs. Record which system passed and which reached users.

Common misconceptions and mistakes

CI/CD always means automatic production deployment. CD may mean continuous delivery with a separate release decision.
A green pipeline proves the product has no defects. It proves only that the implemented checks passed under their test conditions.
Code is the only artifact that matters for AI releases. Models, data transformations, prompts and configuration can change behavior too.

Business use

CI/CD can make software and data changes easier to review, repeat and diagnose. Frequent smaller changes can reduce the amount of work involved in understanding a failed release, provided the process produces useful evidence.

Choose checks that reflect actual failure risks and keep feedback timely. Define who owns broken builds, how release decisions are made and how production problems are detected. Track reliable delivery and recovery outcomes rather than celebrating a large number of deployments without context.

For AI projects, combine deterministic tests with suitable behavioral evaluations. Preserve datasets and criteria used for release decisions, examine important subgroups and scenarios, and monitor production behavior after release. A model can pass a fixed test set while changing user needs or inputs reveal new weaknesses.

Check your understanding

A tested application is always ready to release, but a product owner chooses when it reaches production. Is this compatible with continuous delivery?

Answer: Yes. Continuous delivery establishes reliable release readiness. Automatically deploying each qualifying change would be the additional continuous-deployment practice.

Related terms

Continuous integration
continuous delivery
continuous deployment
build artifact
deployment pipeline
version control
release gate
MLOps
regression testing

Learn next

Read artifact promotion and release traceability. Draw the route from one code or model change to production, labeling the exact version, required checks, release decision and response if the result fails.

Sources

GitHub, Continuous integration: https://docs.github.com/en/actions/get-started/continuous-integration. Primary documentation of automated build and test workflows.

Martin Fowler, Continuous Delivery: https://martinfowler.com/bliki/ContinuousDelivery.html. Primary practitioner explanation of delivery versus deployment.

Databricks, CI/CD for machine learning: https://docs.databricks.com/aws/en/machine-learning/mlops/ci-cd-for-ml. Primary discussion of code, data and model workflows. The evaluation thresholds and analytics case are original illustrations.

Previous: Chunked transfer encoding Next: Circuit (neural network)