CI/CD Fundamentals

Continuous Integration (CI) is the practice of frequently merging code changes into a shared repository, validated by automated builds and tests.

Key principles:

• Commit code to a shared repository multiple times per day
• Each commit triggers an automated build and test suite
• Fix broken builds immediately within minutes
• Keep the build fast (under 10 minutes ideally)

A typical CI workflow: developer pushes code, a build server pulls the latest code, installs dependencies, compiles, runs unit tests, runs integration tests, and reports results. If any step fails, the team is notified.

CI catches bugs early when they are cheapest to fix. A bug found in development costs 1x to fix. The same bug found in production costs 100x. Automated tests provide confidence that changes do not break existing functionality.

Code quality gates enforce standards: test coverage thresholds, linting rules, security scanning, and code review requirements. These prevent low-quality code from reaching production.

Continuous Delivery and Continuous Deployment are often confused but differ in one critical aspect.

Continuous Delivery means every change is ready to deploy to production at any time, but a human approves the final deployment. The pipeline builds, tests, and stages artifacts, but the production release requires manual approval.

Continuous Deployment goes further: every change that passes all stages is automatically deployed to production. No human intervention. This requires extremely high confidence in your test suite and monitoring.

The pipeline stages are typically:

1. Source: pull code from repository
2. Build: compile, package, create artifacts
3. Test: unit, integration, security tests
4. Stage: deploy to staging environment
5. Approval: manual gate (delivery) or automatic (deployment)
6. Deploy: push to production

Choose continuous delivery when you need business approval for releases. Choose continuous deployment when you have comprehensive automated testing and monitoring.

A CI/CD pipeline is a series of automated stages that transform code into running software.

Artifact management stores build outputs (Docker images, JARs, ZIPs) for deployment. Artifacts are versioned, tagged, and stored in registries (ECR for containers, S3 for packages, CodeArtifact for dependencies).

Artifact flow: source code becomes a build artifact, which becomes a deployment artifact, which becomes a running instance. Each stage consumes and produces artifacts.

Environment promotion moves artifacts through environments: dev, staging, prod. Each environment may have different configurations (database URLs, API keys) but the same artifact.

Pipeline as code: Define pipelines in version-controlled files. CodePipeline uses buildspec.yml, GitHub Actions uses .github/workflows, GitLab uses .gitlab-ci.yml. This makes pipeline changes reviewable and auditable.

Measure these metrics to improve your CI/CD pipeline:

Lead time: Time from code commit to production deployment. Elite teams have lead times under one hour.

Deployment frequency: How often you deploy to production. Elite teams deploy on demand, multiple times per day.

Mean time to recovery (MTTR): Time to restore service after a failure. Elite teams recover in under one hour.

Change failure rate: Percentage of deployments causing failures. Elite teams have rates under 5%.

Build duration: Time for a complete pipeline run. Keep under 10 minutes for fast feedback.

Best practices:

• Keep the pipeline fast; optimize slow stages
• Fail fast; run the quickest checks first
• Use caching for dependencies and build artifacts
• Parallelize independent stages
• Maintain a single source of truth for pipeline definitions
• Monitor pipeline health as carefully as application health