What is CI/CD (Continuous Integration & Delivery)?

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

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:

# 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 / 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 — Back4app Flutter SDK
final function = ParseCloudFunction('version');
final response = await function.execute();
if (response.success) {
  print('API version: ${response.result}'); // fresh from the deploy
}

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

// 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

The lineage is worth one sentence: Martin Fowler’s canonical article 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 — 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

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.