Skip to main content
CI/CD Testing Pipelines·Lesson 1 of 5

CI/CD Overview

CI/CD is a set of practices that automate the process of building, testing, and deploying software. Instead of manually running tests and deploying code, a pipeline handles everything — triggered automatically when code is pushed. This lesson covers the core concepts and where testing fits into each stage.

Continuous Integration (CI)

Continuous Integration means every developer merges code into the main branch frequently — at least once a day. Each merge triggers an automated build and test run. The goal is to detect integration issues early, when they are cheap to fix.

Without CI, developers work on isolated branches for days or weeks. When they finally merge, conflicts pile up and bugs become hard to trace. CI eliminates this by making integration a constant, automated process.

A typical CI pipeline:

  1. Developer pushes code to a branch.
  2. CI server detects the push.
  3. It checks out the code, installs dependencies, and builds the project.
  4. It runs the test suite (unit, integration, lint, type checks).
  5. Results are reported back — green checkmark or red failure.

Continuous Delivery (CD)

Continuous Delivery extends CI by ensuring the codebase is always in a deployable state. After tests pass, the artifact is built and prepared for release. Deployment to production still requires manual approval.

The pipeline adds:

  1. Build a production artifact (Docker image, static bundle, etc.).
  2. Deploy to a staging environment.
  3. Run smoke tests against staging.
  4. Wait for manual approval.
  5. Deploy to production.

Continuous Deployment

Continuous Deployment removes the manual approval step. Every change that passes the full pipeline is automatically deployed to production. This requires high confidence in your test suite — there is no human gate.

Companies like Netflix, GitHub, and Etsy practice continuous deployment, shipping hundreds of changes per day. The key enabler is a comprehensive, reliable test suite.

Pipeline Stages

A well-structured pipeline has distinct stages, each serving a purpose:

Push → Install → Lint → Type Check → Unit Tests → Integration Tests → Build → E2E Tests → Deploy

Why This Order Matters

Stages are ordered by speed and cost. Fast checks run first:

  • Lint (seconds): Catches formatting and style issues. No point running tests if the code does not even pass linting.
  • Type Check (seconds): Catches type errors. Faster than running tests.
  • Unit Tests (seconds to minutes): Fast, focused tests that catch logic errors.
  • Integration Tests (minutes): Verify modules work together.
  • Build (minutes): Compile the production artifact. If it fails, there is no point running E2E tests.
  • E2E Tests (minutes): Slow but comprehensive. Run against the built artifact.

If linting fails, the pipeline stops immediately. Developers get feedback in under a minute instead of waiting 15 minutes for E2E tests to run.

Shift-Left Testing

"Shift left" means moving testing earlier in the development process. Instead of testing only at the end, you test at every stage:

  • During coding: Unit tests with TDD, linting, type checking.
  • At commit: Pre-commit hooks run relevant tests.
  • At push: CI runs the full test suite.
  • Before merge: Required status checks block merging broken code.
  • After deploy: Smoke tests and monitoring verify production health.

The further left a bug is caught, the cheaper it is to fix. A bug caught by a linter costs seconds. The same bug found by a user in production costs hours of debugging, a hotfix deployment, and possibly lost customers.

The Cost of Not Automating

Manual testing processes are slow and error-prone:

  • Developers forget to run tests before pushing.
  • Different machines produce different results ("works on my machine").
  • Manual deployments are stressful and mistake-prone.
  • Feedback loops are long — bugs are discovered days after they were introduced.

CI/CD solves all of these. Tests run in a consistent, clean environment every time. Feedback arrives in minutes. Deployments are scripted and repeatable.

What You Will Build

In this course, you will build a complete CI/CD testing pipeline using GitHub Actions. You will automate linting, type checking, unit tests, integration tests, and E2E tests. You will configure pre-merge quality gates, parallelize slow test suites, and set up deployment gates that prevent bad code from reaching production.

Key Takeaways

  • CI integrates code frequently and runs tests on every push.
  • Continuous Delivery ensures the code is always deployable; Continuous Deployment automates the release.
  • Order pipeline stages by speed: lint first, E2E last.
  • Shift testing left — catch bugs as early as possible.
  • Automation eliminates human error and provides fast, consistent feedback.