CI/CD stands for Continuous Integration and Continuous Deployment (or Delivery). It's the practice of automatically testing and shipping code changes — replacing the manual, error-prone "push code and hope" approach with a reliable pipeline that runs the same checks every time.
If Cartara flagged this in your diff, you likely modified a pipeline config file (like .github/workflows/*.yml), added a deployment script, or changed how your app gets built and shipped.
The Two Halves
Continuous Integration (CI)
Every time code is pushed, an automated system:
- Pulls the latest code
- Installs dependencies
- Runs linting and automated tests
- Reports back: passed or failed
The goal is to catch problems immediately — within minutes of writing the code — rather than discovering them days later buried under more changes.
Continuous Delivery / Deployment (CD)
After code passes CI checks, it's automatically prepared for release or shipped directly to users:
- Continuous Delivery — code is ready to deploy at any time; a human still clicks "deploy"
- Continuous Deployment — code that passes all checks ships to production automatically
Most small teams use continuous deployment for low-risk changes and continuous delivery for bigger releases.
Why It Matters
Without CI/CD, developers manually run tests (or forget to), deployments are nerve-wracking, and bugs reach production days after being introduced. Deploying is scary, so it happens infrequently — creating large, risky releases.
With CI/CD, tests run automatically on every change, problems surface immediately, and deployments become routine. Small, frequent releases are safer than large, infrequent ones. CI/CD makes small releases practical.
What a Pipeline Looks Like
Developer pushes code to GitHub
↓
CI pipeline triggers automatically
↓
[Install dependencies]
↓
[Run linter] — checks code style and obvious errors
↓
[Run tests] — automated checks that the app works correctly
↓
[Build the app] — compiles code into deployable form
↓
Pass? → Deploy to staging → Run smoke tests → Deploy to production
Fail? → Notify developer, block deploymentEach step is a gate. If any step fails, the pipeline stops and the developer is notified. Code that breaks tests never reaches users.
What You'll See in Your Code
CI/CD configuration lives in your repository as a YAML file. For GitHub Actions, it's in .github/workflows/:
# .github/workflows/ci.yml
name: CI/CD Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm install
- run: npm test
deploy:
needs: test
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main'
steps:
- uses: actions/checkout@v4
- run: npm run build
- run: npm run deployThis file defines two jobs: test (runs on every push and PR) and deploy (only runs on the main branch, after tests pass).
CI/CD Tools
Platforms with CI/CD Built In (Best Starting Point)
Vercel and Netlify — if you're deploying a frontend or full-stack web app, CI/CD is included. Every push to main triggers a build and deploy. Every pull request gets a preview URL. Zero configuration needed.
Railway and Render — similar auto-deploy capabilities for backend services.
For most small apps, one of these platforms is all you need.
Dedicated CI/CD Tools
When you need more control — custom test suites, multi-service pipelines — dedicated tools give you full flexibility:
| Tool | Notes |
|---|---|
| GitHub Actions | Best default choice; lives in your GitHub repo, generous free tier |
| GitLab CI | If using GitLab |
| CircleCI | Mature, flexible, good free tier |
GitHub Actions is the recommended starting point for most teams.
Preview Deployments
One of the most valuable features of modern CI/CD: every pull request automatically gets its own live URL where you can test the change before it merges.
Vercel and Netlify do this automatically. This means you (or a teammate, or a stakeholder) can click through actual changes in a real environment before they go live. No more "it looked fine in dev."
Common Pitfalls
No tests means CI is just a build checker. A pipeline with no tests will still ship broken code. Even basic tests are better than none.
Slow pipelines. A pipeline that takes 20 minutes discourages frequent commits. Aim for under 5 minutes. Cache dependencies and run tests in parallel.
Secrets in pipeline config. Store API keys and deployment credentials as encrypted secrets in your CI platform — never in the config file itself.
Skipping the pipeline. Bypassing it "just this once" for an urgent fix is how bugs reach production.