CI/CD Fundamentals

Mitch Mommers01/06/2026About 5 min

CI/CD Fundamentals

Before building a delivery pipeline, you need to understand what CI/CD is, why it exists, and how it changes the way teams work.

What is CI/CD?

CI/CD stands for Continuous Integration and Continuous Delivery (or Deployment). These are practices that automate the journey from code commit to production deployment.

Continuous Integration (CI)

Definition: Developers integrate code into a shared repository frequently (multiple times per day). Each integration triggers an automated build and test process.

Core practices:

Commit to main/trunk daily (or more frequently)
Every commit triggers automated build
Automated tests verify correctness
Fast feedback (minutes, not hours)
Fix broken builds immediately

Without CI: Developers work on long-lived feature branches for weeks. Integration happens infrequently. When branches finally merge, conflicts are complex and bugs are hard to trace.

With CI: Small, frequent commits. Integration issues surface immediately. The codebase is always in a known state.

Continuous Delivery (CD)

Definition: Every code change that passes automated tests can be deployed to production at any time. Deployment is automated, but release is a business decision.

Core practices:

Automated deployment to staging/test environments
Production deployment is one click away
Deployment and release are decoupled
Deployment happens frequently, release is controlled

Continuous Deployment vs Continuous Delivery:

Continuous Delivery: Automated pipeline to staging; manual approval for production
Continuous Deployment: Automated pipeline all the way to production (no manual gate)

Most organizations use Continuous Delivery (manual production approval) rather than full Continuous Deployment.

Why CI/CD?

The problem it solves

Traditional "waterfall" release process:

Problems:

Long feedback cycles (months between code and production)
Integration problems discovered late
Big-bang releases are risky
Hard to trace bugs to specific changes
Slow time-to-market

CI/CD approach:

Benefits:

Fast feedback (minutes to hours, not months)
Small changes are easier to test and debug
Frequent releases reduce risk
Bugs are caught early when context is fresh
Faster time-to-market

Core CI/CD concepts

1. Pipeline

A pipeline is the automated sequence of steps that takes code from commit to deployment.

Typical pipeline stages:

Each stage can contain multiple jobs (which may run in parallel).

2. Artifact

An artifact is the deployable package created by the build process.

Key principle: Build once, deploy many times.

Why build once?

Guarantees dev/test/prod run identical code
Faster deployments (no rebuild)
Traceability: artifact metadata links to source commit

Bad practice: Rebuild from source for each environment (dev rebuild ≠ test rebuild)

3. Gates and checks

Gates are decision points in the pipeline that determine whether to proceed.

Types of gates:

Gate Type	Purpose	Fail behavior
Quality gates	Correctness (types, tests)	Block pipeline
Security gates	Safety (vulnerabilities, secrets)	Block or warn
Approval gates	Business decision	Wait for manual approval

Example quality gate:

- script: npm run typecheck
  displayName: 'TypeScript type check'
  # If this fails, pipeline stops immediately

Example security gate (audit mode):

- script: semgrep --config .semgrep.yml
  displayName: 'Security scan'
  continueOnError: "true"  # Report findings but don't block

Example approval gate:

Manual approval required before production deployment
Configured in Azure DevOps Environments UI

4. Environments

Environments are isolated deployment targets (dev, test, staging, production).

Common environment progression:

Environment characteristics:

Dev: Frequent deployments, may be unstable
Test: Automated testing, data similar to production
Staging: Production-like environment, final validation
Production: Live customer traffic, highest stability

5. Triggers

Triggers define when the pipeline runs.

Common trigger types:

Trigger	When	Use case
Branch push	Every commit to `main`/`develop`	CI: validate every change
Pull request	PR opened/updated	Validate before merge
Tag	Git tag created (e.g., `v1.2.3`)	Release builds
Schedule	Cron schedule (e.g., nightly)	Long-running tests, dependency scans
Manual	User clicks "Run"	On-demand deployments

Example trigger configuration (Azure Pipelines):

trigger:
  branches:
    include:
      - main
      - develop
  tags:
    include:
      - v*  # Trigger on version tags like v1.2.3

CI/CD anti-patterns

Anti-pattern 1: Manual testing only

Problem: QA team manually tests before every release.

Why it fails:

Slow feedback (days/weeks)
Testing is a bottleneck
Regression bugs slip through
QA team becomes blocker

Solution: Automate regression tests. QA focuses on exploratory testing and test automation.

Anti-pattern 2: Long-lived feature branches

Problem: Feature branches live for weeks/months before merging.

Why it fails:

Integration conflicts grow over time
No feedback until merge
"Integration hell" when finally merging

Solution: Short-lived branches (< 2 days). Use feature flags for incomplete features.

Anti-pattern 3: Different builds per environment

Problem: Rebuild from source for dev, test, and prod (with different environment variables baked in).

Why it fails:

Dev build ≠ test build ≠ prod build
No guarantee test results apply to prod
Wastes time rebuilding

Solution: Build once, configure at deployment time (environment variables, config files).

Anti-pattern 4: No rollback strategy

Problem: Pipeline can deploy, but can't roll back to previous version.

Why it fails:

Deployment failures require emergency fixes
Pressure to "fix forward" under stress
No safety net

Solution: Store artifacts with version tags. Deployment process can redeploy previous artifact.

Anti-pattern 5: Security scans block everything

Problem: Security scans with any finding (even low-severity) fail the pipeline.

Why it fails:

False positives block legitimate deployments
Teams disable scans to "unblock" work
Security becomes adversarial

Solution: Security scans start in audit mode (continueOnError: "true"). Gradually increase enforcement as teams learn to fix issues.

CI/CD tools landscape

Pipeline orchestration

Tool	Provider	Strengths
Azure Pipelines	Microsoft	Native Azure integration, Windows + Linux
GitHub Actions	GitHub	Excellent developer experience, marketplace
GitLab CI	GitLab	All-in-one platform, Kubernetes-native
Jenkins	Open source	Highly customizable, mature ecosystem
CircleCI	SaaS	Fast, good for containerized apps

This course uses Azure Pipelines because:

Native integration with Azure services
Managed identities for security
Enterprise-ready (access control, audit logs)
Free tier for learning

Artifact repositories

Azure Artifacts: Integrated with Azure Pipelines
JFrog Artifactory: Multi-format repository manager
Nexus Repository: Popular for Java/Maven
Docker Hub / Azure Container Registry: Container images

Testing frameworks

Unit tests: Jest, Pytest, xUnit, Node test runner (Day 3 uses built-in Node test runner)
Integration tests: Supertest (HTTP), Testcontainers (databases)
E2E tests: Playwright, Cypress, Selenium

Summary

CI/CD is a practice, not a tool. The goal is to:

Integrate frequently to catch issues early
Automate testing to ensure correctness
Automate deployment to reduce manual errors
Deliver value faster with less risk

Key principles:

Build once, deploy many times
Fast feedback (minutes, not days)
Automate everything that can be automated
Security is integrated, not a separate phase
Small, frequent changes are safer than big releases

In Day 3 labs, you'll build a CI/CD pipeline that embodies these principles:

Quality gates ensure correctness
Security scans shift left
Artifacts are built once and promoted
Deployment is automated and repeatable