CI/CD

CI/CD stands for Continuous Integration and Continuous Deployment (or Continuous Delivery). Together, they automate the process of testing and releasing code, reducing the time between writing a change and getting it in front of users.

Continuous Integration (CI)

CI is the practice of merging code changes into a shared branch frequently — ideally multiple times a day. Each merge triggers an automated pipeline that:

1. Installs dependencies
2. Runs linters and static analysis
3. Runs automated tests
4. Reports pass or fail back to the pull request

The goal is to catch integration problems early, before they reach the main branch or production.

Continuous Deployment (CD)

CD takes code that has passed CI and deploys it automatically to an environment — staging, production, or both.

• Continuous Delivery means code is automatically deployed to staging and is ready to release to production with a manual click.
• Continuous Deployment goes one step further: every green build is deployed to production automatically, with no human step.

Which approach you use depends on how comfortable you are with fully automated releases and how robust your test suite is.

A Typical Pipeline

Push to branch
  → Install dependencies
  → Lint & static analysis
  → Run tests
  → Build artefacts
  → Deploy to staging
  → Run smoke tests
  → Deploy to production (manual or automatic)

Common Tools

Tool	Notes
GitHub Actions	Built into GitHub, YAML-based, free for public repos
GitLab CI	Built into GitLab, powerful pipeline configuration
CircleCI	Fast builds, good Docker support
Jenkins	Self-hosted, highly configurable, large plugin ecosystem
Bitbucket Pipelines	Built into Bitbucket

GitHub Actions Example

A minimal PHP + Pest pipeline in GitHub Actions:

name: Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
      - run: composer install --no-interaction
      - run: ./vendor/bin/pest

Best Practices

• Keep pipelines fast — slow pipelines get ignored or bypassed
• Fail fast: run the quickest checks first (lint before tests)
• Use environment-specific configuration, never hard-code secrets in pipeline files
• Store secrets as encrypted environment variables in your CI platform
• Notify the team on failures via Slack or email

Related

• Containerisation — packaging your application into images that CI can build, test, and push automatically
• Blue/Green Deployment — zero-downtime releases by switching between two identical environments
• Canary Deployment — rolling out to a small percentage of users before a full release
• Feature Toggles — deploying code to production without activating it
• Trunk-Based Development — the branching strategy that pairs best with continuous deployment