CI/CD (Continuous Integration and Continuous Deployment) Basics

CI/CD Basics

CI/CD stands for Continuous Integration and Continuous Deployment (or Continuous Delivery). It is the practice of automatically testing and deploying your code every time you push a change, removing the manual, error-prone process of deploying by hand.

• Continuous Integration (CI): Every push to the repository automatically runs your tests and checks. If the tests fail, the team is notified immediately before bad code reaches production.
• Continuous Deployment (CD): Once tests pass on the main branch, the code is automatically deployed to production without human intervention.

Why CI/CD Matters

Without CI/CD:

• Developers manually run tests (or forget to)
• Deployment involves SSH-ing into a server and running commands by hand
• Bugs introduced by one developer are discovered late, often in production

With CI/CD:

• Every pull request is automatically tested
• Bad code is caught before it is merged
• Deployment is consistent and reproducible
• You can deploy dozens of times per day safely

GitHub Actions

GitHub Actions is a free CI/CD platform built into GitHub. You define workflows in YAML files stored in .github/workflows/.

mkdir -p .github/workflows

Workflow 1: Run Tests on Every Push

# .github/workflows/test.yml
name: Run Tests

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test
        env:
          NODE_ENV: test
          JWT_SECRET: test-secret-for-ci
          MONGODB_URI: mongodb://localhost:27017/testdb

Workflow 2: Deploy to Production on Merge

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to Heroku
        uses: akhileshns/heroku-deploy@v3.12.14
        with:
          heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
          heroku_app_name: ${{ secrets.HEROKU_APP_NAME }}
          heroku_email: ${{ secrets.HEROKU_EMAIL }}

Secrets like HEROKU_API_KEY are stored in your GitHub repository settings under Settings > Secrets and Variables > Actions — never hardcoded in the YAML file.

A Simple Test to Run in CI

// tests/health.test.js
const request = require('supertest');
const app = require('../index');

describe('Health Check', () => {
  it('should return 200 OK', async () => {
    const res = await request(app).get('/health');
    expect(res.statusCode).toBe(200);
    expect(res.body.status).toBe('ok');
  });
});

npm install --save-dev jest supertest

// package.json
{
  "scripts": {
    "test": "jest --forceExit"
  }
}

Key Takeaways

• CI (Continuous Integration) runs tests automatically on every push, catching bugs before they merge.
• CD (Continuous Deployment) automatically deploys code that passes all tests to production.
• GitHub Actions workflows are defined in YAML files stored in .github/workflows/.
• Store deployment secrets (API keys, tokens) in GitHub Secrets — never in your YAML files.
• A reliable CI/CD pipeline lets teams deploy confidently multiple times per day.

Practice Exercise

1. Create a .github/workflows/test.yml file that runs npm test on every push to main.
2. Install jest and supertest and write a simple test for your GET /health endpoint.
3. Push your changes and watch the Actions tab in GitHub to see the workflow run.
4. Intentionally break a test and verify that the CI workflow fails and shows the error.