Intermediate Time: 2–3 weeks IT & Networking

CI/CD Pipeline with GitHub Actions

Build a complete CI/CD pipeline with automated testing, Docker image building, security scanning, and multi-environment deployment.

CI/CDGitHub ActionsDevOpsDockerTestingDeployment

DifficultyIntermediate

Duration2–3 weeks

Components10 items

Steps6 steps

Introduction

Build a complete CI/CD pipeline with automated testing, Docker image building, security scanning, and multi-environment deployment. This comprehensive guide covers everything from design through implementation, testing, and deployment.

Theory & Background

Define pipeline stages: Trigger (push to branch/PR/tag) → Lint & Format Check → Unit Tests → Integration Tests → Security Scanning (SAST + dependency audit) → Build Docker Image → Scan Image → Push to Registry → Deploy to Staging → Run E2E Tests on Staging → Manual Approval Gate → Deploy to Production → Health Check. Failed stage: stop pipeline, notify developer, don't deploy broken code. Main branch always deployable.

Components & Requirements

10 components required for this project.

#	Component	Purpose	Qty
1	GitHub Repository + Actions	Source control and CI/CD runner	x1
2	Docker Hub / GitHub Container Registry	Docker image registry	x1
3	Jest + Pytest (testing)	Unit and integration test suites	x1
4	SonarCloud / SonarQube	Code quality and security analysis	x1
5	Trivy	Docker image vulnerability scanning	x1
6	Snyk	Dependency vulnerability scanning	x1
7	Kubernetes cluster (deploy target)	Production deployment environment	x1
8	Staging VPS	Pre-production testing environment	x1
9	Slack / Discord webhook	Deployment notifications	x1
10	Grafana (deployment tracking)	Deployment performance monitoring	x1

Step-by-Step Implementation

Follow these 6 steps carefully.

CI/CD Pipeline Design

GitHub Actions Workflow Structure

Create .github/workflows/main.yml. Define trigger: on: push/pull_request for branches. Define jobs: build runs-on: ubuntu-latest. Steps: checkout, setup-node, cache npm modules, install, lint, test, build. Use matrix strategy: test on Node.js 18 and 20 simultaneously, test on ubuntu and windows. Share artifacts between jobs using actions/upload-artifact and download-artifact. Use GitHub-hosted runners for simplicity, self-hosted for speed and privacy.

Automated Testing Integration

Unit tests: npm test or pytest --cov runs in CI. Enforce coverage threshold: if coverage drops below 80%, fail the pipeline. Integration tests: start dependent services (database, Redis) using GitHub Actions services: postgres image, run against real DB. E2E tests: use Playwright or Cypress against staging deployment. Test reports: upload JUnit XML to GitHub, display results in PR. Flaky test management: automatically re-run failed tests once to detect flakes.

Docker Build and Security Scanning

Multi-stage Dockerfile build: stage 1 (builder) installs dependencies and builds, stage 2 (runner) copies only necessary artifacts — reduces image size 70–80%. Build with buildx for multi-arch (amd64 + arm64). Tag strategy: latest (main branch), v1.2.3 (semantic versioned tags), pr-42 (pull request builds). Trivy scan: trivy image --exit-code 1 --severity HIGH,CRITICAL my-image:tag — fail if critical CVEs found. Snyk: snyk test --severity-threshold=high.

Multi-Environment Deployment

Environment strategy: feature branches deploy to ephemeral review environments (auto-deleted when PR merged). Staging: auto-deployed on merge to main. Production: requires manual approval in GitHub Actions. Use GitHub Environments with protection rules: required reviewers for production, deployment frequency limits. Pass secrets via GitHub Encrypted Secrets, not environment variables visible in logs. Rollback: git revert merges fast rollback capability.

Deployment Notifications and Monitoring

Slack notification on: deployment start, success, failure. Include: committer name, commit message, deployment URL, test results summary. Track deployment frequency, lead time, failure rate, MTTR (Mean Time to Recovery) — the 4 DORA metrics for DevOps performance. Post-deployment: health check (curl /api/health returns 200), smoke test (login, key user flows work), rollback trigger if health check fails 3 times in 5 minutes.

Code & Implementation

Core code for .github/workflows/main.yml:

.github/workflows/main.yml
  YAML

name: CI/CD Pipeline  on:   push:     branches: [main, develop]   pull_request:     branches: [main]  env:   REGISTRY: ghcr.io   IMAGE: }  jobs:   test:     runs-on: ubuntu-latest     services:       postgres:         image: postgres:15         env: {POSTGRES_PASSWORD: testpass, POSTGRES_DB: testdb}         options: --health-cmd pg_isready --health-interval 10s     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 -- --coverage --coverageThreshold='{"global":{"lines":80}}'     - uses: actions/upload-artifact@v4       with: {name: coverage, path: coverage/}    build-push:     needs: test     runs-on: ubuntu-latest     if: github.ref == 'refs/heads/main'     steps:     - uses: actions/checkout@v4     - uses: docker/login-action@v3       with:         registry: }         username: }         password: }     - uses: docker/build-push-action@v5       with:         push: true         tags: }/}:}    deploy:     needs: build-push     runs-on: ubuntu-latest     environment: production     steps:     - name: Deploy to Kubernetes       run: |         kubectl set image deployment/catb-web catb-web=}/}:}         kubectl rollout status deployment/catb-web --timeout=5m

Testing & Troubleshooting

Test CI/CD Pipeline with GitHub Actions by verifying each subsystem individually before full integration.

Troubleshooting Tips

Verify power voltages, check ground connections, use serial monitor for debug.

Real-World Applications

*Web application deployment automation

*Mobile app build and distribution

*Infrastructure as Code pipeline

*Machine learning model deployment

*API versioning and deployment

*Microservices independent deployment

*Open source project contribution gates

*Enterprise software release management

Extensions & Next Steps

Implement GitFlow branching strategy automation
Add blue-green deployment with automatic traffic switching
Build canary deployment with gradual traffic shifting
Implement feature flags with LaunchDarkly integration
Add chaos engineering tests in staging pipeline

Interactive Playground

Coming Soon

An interactive simulator will be available here — simulate circuits and run code in-browser without hardware.

Frequently Asked Questions

What is the difference between CI and CD?

CI (Continuous Integration): automatically build and test code on every commit. Purpose: detect integration errors early. Developers integrate code frequently (daily or more). CD (Continuous Delivery): automatically prepare code for deployment to any environment at any time. Requires one-click or automatic deployment to production. CD (Continuous Deployment): automatically deploy to production on every passing build — zero human intervention. Most teams practice CI + Continuous Delivery (not full Deployment) due to compliance and change management requirements.

How do I handle database migrations in a CI/CD pipeline?

Safe migration approach: (1) Write backward-compatible migrations (add nullable columns, don't remove columns immediately). (2) Run migrations before deploying new code version. (3) New code supports both old and new schema simultaneously (for rollback capability). (4) After verifying new code works, run a cleanup migration removing deprecated fields. This blue-green approach ensures zero-downtime migrations. Use Flyway or Liquibase for version-controlled, repeatable migrations with checksums preventing re-execution.