Learn GraphQL - Continuous Integration & Deployment

#Introduction

CI/CD turns deployment from a nerve-racking event into an automated routine. Episode 32 builds a Continuous Integration and Continuous Deployment pipeline specifically for GraphQL projects — with all the gates that keep mistakes out of production.

We'll set up a GitHub Actions pipeline, run automated testing, apply schema checks to block breaking changes, automate deployment with blue-green and canary strategies, and manage releases with semantic versioning.

#CI Pipeline Setup

#GitHub Actions

GitHub Actions runs jobs on every push or pull request:

name: CI
on:
  push:
    branches: [main]
  pull_request:
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - run: bun run lint
      - run: bun run typecheck
      - run: bun run test
      - run: bun run build

Equivalent alternatives: GitLab CI with .gitlab-ci.yml, CircleCI, or Jenkins — all follow the same pattern: checkout, install, lint, test, build.

#Automated Testing in CI

Run the entire testing pyramid (episode 21) in CI: unit tests, integration tests with an in-memory database, and E2E tests for critical flows. Also add a coverage threshold so quality doesn't silently decline. For GraphQL projects, include schema testing as well.

#Schema Checks

#Blocking Breaking Changes

A schema change that breaks clients is the most dangerous bug — because it won't be caught by ordinary application tests. The solution: schema checks in CI:

- name: Check schema changes
  env:
    APOLLO_KEY: ${{ secrets.APOLLO_KEY }}
  run: npx rover graph check kalian@current --schema schema.graphql

rover graph check compares the branch schema against the production schema and blocks breaking changes. Alternative: GraphQL Inspector in CI:

- name: Schema diff
  run: |
    npx @graphql-inspector/cli diff \
      schema/current.graphql schema/branch.graphql

With automatic schema checks, every PR that changes the schema must pass a breaking-change review — preventing surprises for production clients.

#Deployment Automation

#Blue-Green and Canary

Automated deployment needs a safe strategy:

• Blue-green: two identical environments; traffic is switched all at once from the old version (blue) to the new one (green), with one-step rollback.
• Canary: the new version receives a small share of traffic first (for example, 5 percent), then is ramped up gradually while monitored.
• Rollback: the ability to quickly return to a previous version when metrics worsen.

deploy:
  needs: [build, schema-check]
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - run: bun install --frozen-lockfile
    - run: bun run build
    - name: Deploy ke staging
      run: npx vercel deploy --prebuilt --token ${{ secrets.VERCEL_TOKEN }}

Staging is always deployed automatically; production requires manual approval or a green canary metric.

#Code Quality Gates

#Lint, Type Check, and Security Scanning

A CI pipeline should block code that doesn't meet standards:

• Linting: ESLint with GraphQL rules.
• Type checking: TypeScript --noEmit.
• Security scanning: dangerous dependencies with tools like npm audit and Snyk.
• Code coverage: a minimum threshold for new features.

- run: bun run lint
- run: bun run typecheck
- run: npm audit --audit-level=high
- run: bun run test -- --coverage

#Release Management

#Semantic Versioning and Changelogs

For clean releases, apply semantic versioning (major.minor.patch) and keep an automated changelog:

• Breaking change: bump the major version.
• New feature: bump the minor.
• Bug fix: bump the patch.

npx semantic-release

Tools like semantic-release read conventional commits (episode 46) and automatically: determine the version, create the changelog, tag the release, and trigger deployment. This keeps the release history consistent and auditable — important when your users depend on API behavior.

#Conclusion

Key takeaways:

• A CI pipeline runs lint, typecheck, test, and build on every change.
• Schema checks with Rover or GraphQL Inspector block breaking changes.
• Blue-green and canary deployment with rollback keeps releases safe.
• Quality gates cover dependency security and coverage.
• Semantic versioning and automatic changelogs keep releases consistent.
• Automatic staging, gated production, reduces risk.

In the next episode, episode 33, you'll learn about GraphQL Gateway and API Management — gateway architecture, Kong Gateway with plugins, AWS AppSync as a managed service, Hasura for instant GraphQL from a database, and API management with API keys and a developer portal. Your API will be ready for enterprise-scale management!