What is CI/CD?

Delivery and operations

CI/CD means Continuous Integration and Continuous Delivery or Continuous Deployment. In practice, it is a disciplined way to move software changes from idea to live service with less guesswork and better control. Teams commit changes into version control, run automated checks, build deployable artefacts, and promote releases through environments using defined rules. Continuous Integration is about merging and testing changes frequently. Continuous Delivery keeps software in a releasable state, with a human deciding when production release happens. Continuous Deployment automates that production release once the required checks pass.

What this means

A useful way to think about CI/CD is as an operating system for software change. It is not a single tool, and it is not just a faster release button. It is a repeatable workflow that answers basic but important questions every time something changes: who changed what, what tests ran, what was built, what environment was used, who approved the release, what happened after deployment, and how do we roll back if things go wrong.

For a small or mid-sized organisation, that discipline matters more than the fashionable label. A modest pipeline that pulls code from a repository, runs unit and integration tests, scans dependencies, packages a container image, records deployment logs, and requires approval before production can be more valuable than an over-engineered platform. The point is not to imitate hyperscale engineering culture. The point is to make routine change safer, easier to review, and less dependent on one person remembering the right sequence.

That matters for AI-enabled systems too. An internal document assistant, a customer-facing model API, a retrieval workflow, or a reporting dashboard still runs on ordinary software components, environments, identities, secrets, gateways, and logs. The intelligence layer does not remove the need for disciplined delivery. If anything, it increases the need for it.

Why it matters

Leaders often hear CI/CD described as a productivity practice, but the deeper value is operational reliability. If your organisation changes software that handles transactions, staff workflows, integrations, personal data, model routing, or billing logic, every release is a business risk event as well as a technical one. CI/CD reduces that risk when it gives you smaller changes, earlier feedback, clearer audit trails, and more predictable release behaviour.

Frequent integration helps teams spot conflicts earlier. Automated tests catch some defects before they become incidents. Reproducible builds reduce "works on my machine" arguments. Environment separation reduces the chance that a developer shortcut becomes a production problem. Deployment logs and artefact provenance make investigation easier if something breaks.

CI/CD also matters because software supply chain risk now sits close to day-to-day delivery. Modern teams pull packages, build containers, call external APIs, use plugins, run reusable actions, and deploy through automation with powerful credentials. Even a small company using a managed repository and cloud build service is operating a supply chain. For AI-enabled products, the point becomes even more practical: changes to prompts, retrieval logic, SDK versions, rate limits, or model fallbacks can quietly affect quality, confidentiality, cost, and customer trust.

How it works

A CI/CD pipeline usually starts in version control. A developer or platform engineer opens a branch, makes a change, and submits it for review. Protected branches, review rules, and clear ownership are the first controls. Once a change is pushed, the pipeline runs automated work such as linting, unit tests, integration tests, dependency checks, static analysis, and build steps. If those pass, the pipeline produces an artefact such as a package, container image, or deployment bundle.

The next step is promotion. In Continuous Delivery, the artefact moves through environments but a human still approves release to production. In Continuous Deployment, production release is automated once the required checks pass. That can work well for low-risk, well-tested services, but only if tests, observability, and rollback are meaningful.

Good pipelines do more than "run tests and ship". Build workers should be hardened. Secrets should come from managed stores or tightly controlled pipeline variables, not from source code or random scripts. Permissions should be narrow. Artefacts should be identifiable and ideally signed or attested so teams can verify what was built and by which process. Sensitive environments should not depend on ad hoc console access if the organisation expects predictable releases.

Environment separation matters here. Development, test, staging, and production should not blur together just because the cloud console makes that easy. Logs matter too. If a deployment failed at 14:07, teams should know which commit, pipeline run, artefact digest, configuration version, and approval were involved. In AI-adjacent delivery, the checks may also include prompt evaluation, retrieval quality thresholds, model routing tests, or fallback behaviour.

Examples

Imagine a SaaS company that exposes an API used by finance teams. A developer changes the logic that validates invoice uploads. Under a good CI/CD process, the change is reviewed in a pull request, merged into the main branch, tested automatically, built into a container image, scanned for dependency issues, and deployed first to staging. Product and operations staff test known sample files. Only then is the release approved for production. If a defect appears, the team can trace the exact build and roll back quickly.

Now imagine an internal AI assistant that helps staff retrieve policy documents and draft responses. The team updates the retrieval library, changes chunking settings, and adds a fallback model provider. None of those changes looks dramatic on its own. Together they could affect quality, confidentiality, cost, or resilience. A disciplined pipeline lets the team test known prompts, verify redaction behaviour, and decide whether a human approval is needed before release.

A third example is an application change that also updates Infrastructure as Code and gateway policy. CI/CD becomes the coordination layer that moves related changes together instead of relying on disconnected console clicks and memory.

One more pattern is progressive release. A team deploying a new search ranking service can release first to internal users or a small customer cohort, watch error rates and support tickets, and then widen exposure. That is still CI/CD. It recognises that release is not a single binary event. The pipeline can help stage the change, but operators still need metrics, ownership, and a clear stop condition.

Common misunderstandings

One common misunderstanding is that CI/CD simply means speed. Speed can be a result, but the core idea is repeatability with controls. A team that releases every hour without meaningful testing, logging, approval logic, or rollback is not doing CI/CD well; it is just automating risk.

Another misunderstanding is that Continuous Delivery and Continuous Deployment are the same. They are related, but the release decision is the important difference. Continuous Delivery keeps software releasable and usually expects a human approval before production. Continuous Deployment automates the production release itself. For some low-risk services that is sensible. For software that changes financial calculations, identity flows, or safety logic, automatic release may not be the right default.

There is also a habit of treating CI/CD as a developer-only concern. In reality, good delivery involves engineering, platform operations, security, service ownership, and sometimes governance colleagues when changes affect personal data or customer-facing behaviour.

Risks and boundaries

CI/CD can fail in very ordinary ways. Weak tests create false confidence. Fragile rollback plans turn a small defect into an outage. Unclear ownership means everyone assumes someone else approved the risky release. Pipelines that rely on broad credentials can expose cloud accounts, signing keys, or production services if a runner is compromised. Reusable third-party actions, plugins, and packages can extend the attack surface.

Secrets deserve special attention. Pipelines often handle high-privilege credentials because they need to build, scan, and deploy across environments. If these are hard-coded, over-shared, or leaked in logs, the pipeline becomes a privileged attack path. Build integrity matters for the same reason. If untrusted pull requests can trigger powerful deployment jobs, or if self-hosted runners are poorly isolated, the controls exist on paper but not in practice.

Over-automation is another risk. Teams can become attached to the idea that every passing test should produce a release. That is fine for some low-risk changes, but not every service has the same blast radius. CI/CD should support judgement, not erase it. For AI-enabled systems, passing pipeline checks does not prove that a feature is safe or suitable in every context; it only proves that the defined checks passed.

What to do next

Leaders do not need to design pipelines line by line, but they should ask for a clear release model. Start by identifying which services matter most, what a release actually includes, and where human approval is still required. Make sure version control, review rules, automated tests, environment separation, deployment logging, and rollback exist for those services before chasing fancier automation.

Then look at the pipeline as a privileged system in its own right. Ask who can change it, who can approve releases, where secrets live, how artefacts are identified, and whether the organisation can reconstruct what happened after an incident. If your team is releasing AI-enabled features, ask what checks exist for prompt changes, retrieval updates, model routing, gateway policy, and fallback behaviour.

Aim for boring reliability over performative sophistication. A small, well-understood CI/CD setup with clear ownership is better than a sprawling platform no one can explain.

FAQs

Does CI/CD mean every change goes live automatically?

No. Continuous Delivery and Continuous Deployment are not identical. In Continuous Delivery, the software is kept ready for release but a person or formal approval step usually decides when production release happens. In Continuous Deployment, the release itself is automated once checks pass. Many organisations use a mixture, with more automation for low-risk services and tighter approval for higher-impact changes.

Is CI/CD only relevant for software engineering teams?

No. Engineering runs the tooling, but the consequences touch operations, security, product, customer support, and leadership. Release frequency, rollback quality, auditability, and incident response all affect the wider organisation. If your company ships customer portals, internal workflow systems, or AI-enabled assistants, CI/CD is part of service governance, not just a developer convenience.

Does a CI/CD pipeline make software secure or compliant?

Not by itself. A pipeline can enforce useful controls such as reviews, tests, signing, environment separation, and deployment logs, but it cannot guarantee secure design, lawful processing, or suitable business decisions. It helps organisations apply controls consistently. Whether those controls are sufficient depends on the software, data, users, and risk involved.

How does CI/CD relate to MLOps and LLMOps?

MLOps and LLMOps extend delivery discipline into model, data, evaluation, and serving workflows, but they do not replace ordinary software delivery practice. The service still needs code reviews, tested releases, controlled configuration, secrets handling, deployment logging, monitoring, and rollback. In many organisations, CI/CD is the backbone that carries those wider operational workflows.

Sources

‹ What is DevOps?

What is IaC? ›