What Is CI/CD? A Practical Guide to Continuous Integration and Delivery

CI/CD stands for Continuous Integration and Continuous Delivery (or Continuous Deployment). It's the practice of automating the steps between writing code and getting it to production — building, testing, and deploying software automatically instead of doing it by hand.

Here's the simplest way to think about it: every time a developer pushes code, a machine picks it up, runs the tests, builds the artifact, and either makes it ready for deployment (Continuous Delivery) or deploys it automatically (Continuous Deployment). If anything fails along the way, the team gets notified immediately.

CI vs. CD: What's the Actual Difference?

These three terms get mixed up constantly. Here's the distinction:

flowchart LR
    A[Code Push] --> B[Build & Test]
    B --> C[Deployable Artifact]
    C --> D{Manual Approval?}
    D -->|Yes| E[Continuous Delivery]
    D -->|No| F[Continuous Deployment]

    style B fill:#4a9eff,color:#fff
    style E fill:#2ecc71,color:#fff
    style F fill:#e67e22,color:#fff

Continuous Integration (CI) — Developers merge code into a shared branch frequently (multiple times a day, ideally). Every merge triggers an automated build pipeline: the code is compiled, dependencies are installed, and tests run. If anything fails, the team knows within minutes.

The key word is continuous. CI doesn't work if developers merge once a week. The value comes from catching integration problems immediately — two developers changing the same function, a broken dependency, a test regression — before they compound into bigger problems.

Continuous Delivery (CD) — Extends CI by ensuring the software is always in a deployable state. After the build and tests pass, the artifact is ready to go to production at any time. The actual deployment still requires a human decision — someone clicks a button or approves a release.

Continuous Deployment (CD) — Takes it one step further: every change that passes the automated tests is deployed to production automatically. No human approval, no manual step. This requires high confidence in your test suite and monitoring — if a bug slips through, it's live immediately.

Most teams practice Continuous Delivery, not Continuous Deployment. The human approval step exists for good reason: not every passing test suite means the release is ready for users.

What a CI/CD Pipeline Looks Like

A CI/CD pipeline is the sequence of automated steps that code goes through from commit to production. Here's a typical pipeline:

flowchart LR
    A[Commit] --> B[Build]
    B --> C[Unit Tests]
    C --> D[Integration Tests]
    D --> E[Build Artifact]
    E --> F[Deploy to Staging]
    F --> G[Smoke Tests]
    G --> H[Deploy to Production]

And here's what that looks like as a real GitHub Actions configuration:

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline
on:
  push:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build
          path: dist/

  deploy-staging:
    needs: build-and-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build
          path: dist/
      # Deploy to staging server
      - run: ./scripts/deploy.sh staging

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production  # Requires manual approval
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: build
          path: dist/
      - run: ./scripts/deploy.sh production

The environment: production line is what makes this Continuous Delivery instead of Continuous Deployment — it pauses and waits for manual approval before deploying to production.

The CI/CD Pipeline Stages Explained

1. Source Stage

Everything starts with a code commit. The developer pushes to a Git branch, creates a pull request, or merges to main. The CI/CD tool detects the change via a webhook and kicks off the pipeline.

2. Build Stage

Dependencies get installed, code gets compiled or bundled. For a Node.js project, that's npm ci && npm run build. For Java, it's mvn package. For Go, go build. The output is a deployable artifact — a compiled binary, a Docker image, a bundled dist/ directory.

Build scripts define exactly what happens at this stage. They should be deterministic: the same commit should always produce the same artifact.

3. Test Stage

The automated test suite runs against the freshly built code. This typically includes:

• Linting and static analysis — catch style issues and potential bugs without running the code
• Unit tests — verify individual functions and components work correctly
• Integration tests — verify components work together (API endpoints, database queries)
• Security scanning — check dependencies for known vulnerabilities

If any test fails, the pipeline stops. This is the primary quality gate — it's what makes CI/CD valuable. Broken code never makes it past this stage.

4. Artifact Stage

A successful build produces an artifact that's stored somewhere retrievable:

5. Deploy Stage

The artifact gets deployed to an environment. Most teams use at least two:

• Staging — mirrors production, used for final validation
• Production — the live environment serving real users

Deployment tools like DeployHQ handle this step: they connect to your servers via SSH/SFTP, push the built artifact, run deployment scripts, and optionally perform zero-downtime switches so users never see an interruption.

6. Verification Stage

After deployment, automated smoke tests verify the application is running correctly in the new environment. Health checks, critical-path tests, and monitoring alerts confirm the release is stable. If anything looks wrong, automated or manual rollback kicks in.

CI/CD Tools Compared

The most common CI/CD tools, and what sets them apart:

Most of these tools handle the CI part (build and test). For the CD part (deployment), many teams use a dedicated deployment tool. DeployHQ specializes here: it connects to your repository, runs build commands on its own servers, and deploys the result to your infrastructure — whether that's a VPS, shared hosting, AWS, or any other server.

CI/CD vs. DevOps

DevOps is the philosophy. CI/CD is the practice that makes it work.

DevOps says: Development and operations teams should collaborate, automate, and share responsibility. CI/CD is how you automate the delivery process. You can have DevOps without CI/CD (though it won't be very effective), and you can have CI/CD without DevOps (but you'll miss the cultural benefits).

In practice, CI/CD is usually the first thing teams implement when adopting DevOps — it delivers immediate, measurable results: faster releases, fewer failed deployments, quicker recovery times.

Common CI/CD Mistakes

Testing only the happy path. If your test suite only verifies that things work when inputs are correct, you'll discover edge cases in production. Test failure modes, boundary conditions, and error handling.

No staging environment. Deploying directly from CI to production means every bug is a production incident. A staging environment that mirrors production catches environment-specific issues before they affect users.

Slow pipelines. A 30-minute pipeline means developers context-switch while waiting, batch up changes to avoid running it, and skip it for small fixes. Aim for under 10 minutes. Use caching, parallelize tests, and run fast checks first.

Secrets in the repository. API keys, database passwords, and tokens should never be committed to Git. Use your CI/CD tool's secret management, environment variables, or a vault like HashiCorp Vault.

No rollback strategy. If a deployment breaks production, you need to revert fast. Automated rollbacks, blue-green deployments, or canary releases give you a safety net.

Treating CI/CD as set-and-forget. Pipelines need maintenance. Dependencies get outdated, test suites grow slow, build images fall behind. Schedule regular pipeline reviews, just like code reviews.

Setting Up CI/CD from Scratch

If you don't have CI/CD yet, here's a practical path:

Week 1: Automate the build. Pick a CI tool (GitHub Actions if you're on GitHub — it's the simplest starting point). Write a pipeline that runs install → lint → test → build on every push. Nothing fancy, just automated.

Week 2: Add deployment. Connect a deployment tool like DeployHQ to your repository. Configure it to deploy to a staging environment when code is merged to main. Now you have Continuous Delivery.

Week 3: Add staging verification. Run smoke tests against staging after deployment. If they pass, the release is ready for production. If they fail, the deployment is flagged.

Week 4: Streamline production deployments. Add a production deployment step with manual approval. Set up deployment notifications so the team knows when a release goes out. Configure rollback procedures.

After this, you have a working CI/CD pipeline. Everything else — parallelized tests, caching, security scanning, canary releases — is optimization on top of a solid foundation.

FAQs

What triggers a CI/CD pipeline? Most commonly, a git push or pull request event. Pipelines can also be triggered by schedules (nightly builds), webhooks from external services, or manual dispatch.

Do I need CI/CD for a static website? Yes — even static sites benefit from automated builds and deployments. A pipeline can run HTML validators, check for broken links, optimize images, and deploy to a CDN automatically. It's less about the complexity of the build and more about eliminating manual steps.

Can I use CI/CD with FTP-based hosting? Yes, though FTP has significant limitations for CI/CD workflows. Tools like DeployHQ support FTP/SFTP deployment as part of an automated pipeline, so you can still automate even if your hosting doesn't support modern deployment methods.

How much does CI/CD cost? Most CI tools offer free tiers: GitHub Actions gives 2,000 minutes/month for free repos, GitLab CI provides 400 minutes/month. For deployment, DeployHQ offers a free tier for small projects. The real cost isn't the tooling — it's the time investment to set it up and write good tests.

What's the difference between CI/CD and a build pipeline? A build pipeline covers the build and validation steps (compile, test, produce artifact). A CI/CD pipeline adds deployment stages on top. Every CI/CD pipeline contains a build pipeline; not every build pipeline includes deployment.

Ready to automate your deployment workflow? DeployHQ connects to GitHub, GitLab, and Bitbucket, runs your build commands, and deploys to any server — with zero-downtime releases and instant rollback. Start your free trial.

Have questions? Reach out at support@deployhq.com or find us on X (@deployhq).