---
term: 'CI/CD (Continuous Integration & Delivery)'
seoTitle: 'What is CI/CD? Continuous Integration & Delivery Explained'
headline: 'What is CI/CD (Continuous Integration & Delivery)?'
slug: ci-cd
category: cloud-architecture
shortDefinition: 'CI/CD is a practice that automates building, testing, and releasing code, so every change moves from commit to production in small steps.'
relatedTerms:
  - no-ops-development
  - containerization
  - kubernetes
  - backend-boilerplate-code
  - cloud-code-serverless-functions
contrastsWith:
  - no-ops-development
faq:
  - question: 'What does CI/CD stand for?'
    answer: 'Continuous Integration and Continuous Delivery — with a built-in ambiguity every practitioner should know: the "CD" can also mean continuous deployment. Delivery keeps a human approval before production; deployment removes it. When someone says "we do CI/CD," the useful follow-up is always which CD they mean.'
  - question: 'What is continuous integration?'
    answer: 'The practice of merging small changes into a shared mainline frequently — at least daily in the canonical definition — with every merge triggering an automated build and test run. The point is fast feedback: integration problems surface within minutes of being created instead of weeks later during a release crunch.'
  - question: 'What is the difference between continuous delivery and continuous deployment?'
    answer: 'One manual approval step. Under continuous delivery, every change is automatically built, tested, and kept releasable, but a human decides when production actually updates. Under continuous deployment there is no gate: every change that passes the pipeline goes live automatically, and only a failing test stops it.'
  - question: 'What is a CI/CD pipeline?'
    answer: 'The automated workflow a change travels from commit to production: source trigger, build, automated tests, delivery to a staging environment, and deployment. Each stage must pass before the next runs, so the pipeline acts as a quality gate that every change clears the same way — no special cases, no deploy heroics.'
  - question: 'What are the DORA metrics?'
    answer: 'The industry-standard way to measure delivery performance, from the DORA research program: deployment frequency, change lead time, change failure rate, failed-deployment recovery time, and — added most recently — deployment rework rate. The headline research finding is that speed and stability are not a trade-off: top performers score high on both.'
  - question: 'Is CI/CD the same as DevOps?'
    answer: 'No — DevOps is the broader culture of unifying development and operations; CI/CD is its automation backbone. You can adopt CI/CD tooling without the culture (it helps less than expected), and preach the culture without the automation (it changes less than promised). The practices reinforce each other but name different things.'
  - question: 'What tests run in a CI/CD pipeline?'
    answer: 'Layered by speed: unit tests and static analysis run on every commit because they are fast; integration tests verify components against real dependencies; end-to-end, performance, and security scans run in later stages or on a schedule because they are slow. The design rule: the faster the feedback, the earlier the stage.'
  - question: 'Do small teams need CI/CD?'
    answer: 'They need the practice more than the plumbing. Even a two-person team benefits from automated tests on every change and one-command deploys — that is CI/CD in substance. What small teams should avoid is operating heavyweight pipeline infrastructure; hosted runners or platforms with built-in deployment reduce the practice to configuration.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Continuous Integration — Martin Fowler (updated 2024)'
    url: 'https://martinfowler.com/articles/continuousIntegration.html'
  - name: 'Continuous Delivery — Martin Fowler'
    url: 'https://martinfowler.com/bliki/ContinuousDelivery.html'
  - name: 'DORA metrics guide (dora.dev)'
    url: 'https://dora.dev/guides/dora-metrics-four-keys/'
  - name: 'CI/CD (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/CI/CD'
cta:
  title: 'Deployment without the pipeline plumbing'
  text: 'Back4app collapses the delivery half of CI/CD: Cloud Code functions deploy in one CLI command or straight from a Git repository, with the database, auth, and APIs already live. Keep your tests; skip the runner farm.'
  linkText: 'Start building free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-23'
translationKey: ci-cd
---

**CI/CD is a practice that automates building, testing, and releasing code, so every change moves from commit to production in small steps.** The name compresses two ideas — continuous integration (merge and verify constantly) and continuous delivery (keep every change releasable) — plus a famous ambiguity: the second "D" can also mean continuous *deployment*, where nothing but a failing test stands between a commit and production.

## Key takeaways

| Question | Answer |
| --- | --- |
| What it is | Automation that turns "release day" into a non-event that happens constantly |
| CI | Merge small changes daily; every merge builds and tests automatically |
| The two CDs | Delivery keeps a human approval before production; deployment removes it |
| Why it works | Small changes fail small; fast feedback catches bugs minutes after creation |
| How it's measured | The five DORA metrics — and speed and stability rise together |

## What a pipeline actually looks like

The whole practice fits in one config file — this is the artifact every "CI/CD explained" page describes and almost none show:

```yaml
# pipeline.yml — the automation that replaces "deploy day"
on: push to main

jobs:
  build:
    steps:
      - checkout
      - run: npm ci && npm run build
  test:
    needs: build
    steps:
      - run: npm test            # unit + integration, every commit
      - run: npm run lint        # static analysis
  deploy:
    needs: test
    approval: manual             # delete this line → continuous deployment
    steps:
      - run: npm run deploy
```

Minutes after that last step runs, every client is already calling the new backend version — which is the entire point:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// Seconds after `b4a deploy`, every client is calling the new version
const version = await Parse.Cloud.run('version');
console.log(`API version: ${version}`); // no pipeline YAML, no runners
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('version');
final response = await function.execute();
if (response.success) {
  print('API version: ${response.result}'); // fresh from the deploy
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("version") { result in
  if case .success(let version) = result {
    print("API version: \(version)") // fresh from the deploy
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("version", hashMapOf()) { version, e ->
  if (e == null) Log.d("API", "version: $version") // fresh from the deploy
}
```

## CI vs. continuous delivery vs. continuous deployment

| Dimension | Continuous integration | Continuous delivery | Continuous deployment |
| --- | --- | --- | --- |
| Scope | Merge + build + test | …plus always-releasable artifacts | …plus automatic release |
| Trigger | Every commit to mainline | Every passing build | Every passing build |
| Human gate | None (tests are the gate) | **Yes — a release approval** | **None** |
| Production updates | When someone releases | When someone clicks | Continuously |
| Best fit | Everyone | Regulated releases, marketing-timed launches | Web backends, SaaS, high-trust test suites |

```mermaid
flowchart LR
  accTitle: A CI/CD pipeline
  accDescr: Commits trigger automated build and test stages; passing changes reach staging, then cross either a manual approval gate under continuous delivery or no gate at all under continuous deployment into production.
  A[Commit] --> B[Build] --> C[Automated tests] --> D[Staging]
  D --> E{Manual approval?}
  E -- "yes — continuous delivery" --> F[Production]
  E -- "no gate — continuous deployment" --> F
```

The lineage is worth one sentence: [Martin Fowler's canonical article](https://martinfowler.com/articles/continuousIntegration.html) defined CI in 2000, the 2010 book *Continuous Delivery* extended it to the release process, and DevOps made the pair its automation backbone. One sharp edge from Fowler still cuts today: running a build server against long-lived feature branches is "semi-integration" — real CI means the mainline integrates everyone's work at least daily.

## The pipeline, stage by stage

- **Source.** A commit or merge triggers everything. No manual builds, ever — if it isn't triggered, it isn't CI.
- **Build.** Compile, resolve dependencies, produce the artifact (bundle, container image) that every later stage reuses — build once, promote everywhere.
- **Test.** Fast checks first: unit tests and linting on every commit; integration tests against real dependencies next; end-to-end, performance, and security scans in later or scheduled runs. Feedback speed decides stage order.
- **Deliver.** The artifact lands in a production-like staging environment. Under continuous delivery, it waits here — releasable — for a human yes.
- **Deploy.** Production. Mature pipelines deploy gradually — a canary slice or a parallel blue/green environment — so a bad change is a contained rollback, not an outage.

## Measuring it: the DORA metrics

"Are we good at delivery?" has a standard answer: the [DORA research program's five metrics](https://dora.dev/guides/dora-metrics-four-keys/) — deployment frequency, change lead time, change failure rate, failed-deployment recovery time, and deployment rework rate. The research's most quoted finding is that the classic speed-vs-stability trade-off is false: teams that deploy most often also break least, because small frequent changes are individually low-risk and fast to diagnose. If your pipeline work doesn't move one of the five, it's plumbing, not progress.

## Common use cases

- **Web and API backends** — the natural home of full continuous deployment: high change volume, instant rollback, no install step.
- **Mobile apps** — CI plus continuous *delivery*: pipelines build, test, and stage every change, while store review makes the final push inherently gated.
- **Teams scaling past one deployer** — the pipeline replaces the one person who "knows how to release" with a process anyone can run.
- **Regulated environments** — the approval gate becomes a feature: full automation up to the line, an auditable human decision at it.
- **Open-source projects** — every pull request built and tested automatically is CI serving as the project's front door.

## Should you gate production? A decision matrix

| Choose continuous deployment when… | Keep the delivery gate when… |
| --- | --- |
| The test suite is trusted with production | Test coverage is still growing into that trust |
| Rollback is one command | Rollback is a project |
| Users expect invisible, constant updates | Releases align with marketing or contract dates |
| The product is a web backend or SaaS | The product ships through app-store review |
| Failures degrade gracefully behind feature flags | A bad release has regulatory consequences |

The honest sequencing: earn deployment by practicing delivery — automate everything up to the gate, watch the failure rate, then remove the gate when it's no longer doing anything.

## Limitations and trade-offs

- **The pipeline is code you own.** Runners, YAML, caches, secrets — it all needs maintenance, and at some team sizes the pipeline becomes its own product with its own on-call.
- **Flaky tests poison everything.** A suite that fails randomly trains people to click "retry," which quietly converts continuous deployment back into manual deployment with extra steps.
- **Culture is a prerequisite, not a byproduct.** Small merges, mainline development, and fixing red builds immediately are habits; buying a pipeline doesn't install them.
- **Speed without observability is gambling.** Deploying constantly is only safe if you can see failures fast — monitoring and alerting are part of the practice, not an add-on.
- **The last mile varies.** Databases, migrations, and stateful services resist "just redeploy"; the pipeline needs strategies (expand-contract migrations, feature flags) that no YAML writes for you.

## CI/CD on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Its effect on CI/CD is subtraction on the delivery side: Cloud Code deploys in one CLI command or directly from a Git repository, and the standard backend — database, auth, APIs — never appears in your pipeline at all because there's nothing to build or release. What remains is the half you should keep: your tests, running on every commit, in front of a deploy step that's now one line long.