DEV Community: miruky

A Field Guide to AWS CI/CD: CodeBuild, CodeDeploy, and CodePipeline End to End

miruky — Tue, 26 May 2026 12:09:17 +0000

Introduction

Hi, I'm miruky.

If you have ever tried to wire up CI/CD on AWS, you already know the names: CodeCommit, CodeBuild, CodeDeploy, CodePipeline. Individually each one is small. The real question is how to glue them into a flow that actually ships software safely.

Where does the source live? Where does the build run? How do artifacts move? How do you deploy to EC2, ECS, or Lambda? Who approves the production push? What happens when something fails? CI/CD only starts paying back when all of these connect in a single line.

This article walks through that end to end, from the fundamentals of CI/CD to each service, the config files, a complete hands-on pipeline, and day-2 operations.

Status note as of mid-2026

AWS CodeCommit was restricted to existing customers from July 2024, then returned to full general availability on November 24, 2025. Amazon CodeCatalyst and Amazon CodeGuru Reviewer remain restricted for new customers. This article reflects the post-GA state, so CodeCommit is back on the table next to GitHub integration.

Scope

Area	Contents
CI/CD fundamentals	CI, Continuous Delivery, Continuous Deployment, the base flow
CodeCommit	Service overview, GA return, migration to GitHub, comparisons
GitHub integration	Git setup, SSH keys, CodeConnections, connection checks
CodeBuild	How it works, pricing, compute types, project creation
`buildspec.yml`	Phases, environment variables, secrets, cache, Docker, batch, reports, webhooks
CodeDeploy for EC2	`appspec.yml`, lifecycle, agent, EC2 deployment, deployment groups
Deployment strategies	In-Place, Blue/Green, load balancers, automatic rollback, CloudWatch alarms
ECS and Lambda	Blue/Green, Canary, Linear, test hooks, Lambda aliases
CodePipeline	Stages, actions, artifacts, V1 vs V2, pricing
CodePipeline V2	Trigger filters, variables, manual approval, SNS, EventBridge, JSON definitions
Advanced layouts	Multi-stage, parallel actions, multi-source, CloudFormation, cross-account, cross-region, Lambda Invoke
End-to-end hands-on	GitHub to EC2 CI/CD, validation, failure behavior, cleanup
Production operations	IAM, secrets, S3/KMS, cost, monitoring, logs, troubleshooting, team practices

CI/CD fundamentals
The AWS Code family at a glance
Source control and where CodeCommit stands now
GitHub and CodeConnections setup
CodeBuild fundamentals
buildspec.yml in practice
CodeDeploy fundamentals
Deploying to EC2
Deployment strategies and rollback
Canary deployments to ECS and Lambda
CodePipeline fundamentals
CodePipeline V2 in practice
Advanced pipeline design
Building a CI/CD pipeline from scratch
Security and IAM design
Cost, monitoring, and logs
Troubleshooting
Patterns and team practices

1. CI/CD fundamentals

1-1. CI

CI stands for Continuous Integration: developers merge code into the repository often, and every merge triggers builds, tests, and static analysis automatically.

Item	Detail
Goal	Catch integration bugs fast
Triggers	push, pull request, manual run
Automated steps	Compile, unit tests, lint, format check
Central AWS service	CodeBuild

Without CI, missed tests, environment drift, and post-merge breakage tend to surface late. The point of CI is to verify small changes quickly.

1-2. CD

CD has two meanings, and they are not interchangeable.

Term	Meaning	Production push
Continuous Delivery	Keep production-ready at all times	Manual approval gate
Continuous Deployment	Auto-promote to production after tests	Fully automatic

In practice, most teams want a human gate before production, so Continuous Delivery is more common. CodePipeline's manual approval stage maps cleanly to that.

1-3. End-to-end CI/CD flow

flowchart TB
    A[Source control] --> B[Build]
    B --> C[Test]
    C --> D[Artifact storage]
    D --> E[Staging deploy]
    E --> F[Manual approval]
    F --> G[Production deploy]
    G --> H[Monitoring and logs]

On AWS, source lives in CodeCommit or GitHub, builds run in CodeBuild, deployments are driven by CodeDeploy, and CodePipeline orchestrates the whole flow.

2. The AWS Code family at a glance

2-1. The four core services

Service	Role	Main config file
AWS CodeCommit	Managed Git repository	none
AWS CodeBuild	Build and test	`buildspec.yml`
AWS CodeDeploy	Deploy to EC2, ECS, Lambda	`appspec.yml`
AWS CodePipeline	Orchestrate the CI/CD flow	Pipeline JSON, console config

CodePipeline does not build or deploy by itself. It chains actions like Source, Build, Deploy, and Approval, and manages order, artifacts, and what happens on failure.

2-2. CI/CD steps mapped to AWS services

Step	AWS service	Notes
Source control	CodeCommit, GitHub, GitLab, Bitbucket	CodeConnections is the bridge for non-AWS sources
Build	CodeBuild	EC2 compute or Lambda compute
Artifact storage	S3, ECR	ZIPs, static files, Docker images
Deploy	CodeDeploy, CloudFormation, ECS, S3	The right action depends on the target
Approval	CodePipeline Manual approval	Pre-production gate
Notifications	SNS, EventBridge, AWS Chatbot	Failure alerts, approval requests
Observability	CloudWatch, CloudTrail	Logs, metrics, audit trail

2-3. Choosing services in 2026

Goal	First choice	Notes
Stay fully inside AWS for Git	CodeCommit	Returned to GA in November 2025
Develop primarily on GitHub	GitHub + CodeConnections	Most common in practice
Only the build in AWS	CodeBuild	Plays well alongside GitHub Actions
Safe EC2 rollout	CodeDeploy	Needs agent and `appspec.yml`
Staged rollout for ECS or Lambda	CodeDeploy	Canary, Linear, AllAtOnce
Tie multiple steps together	CodePipeline V2	Default to V2 for new pipelines

2-4. Alternatives outside the Code family

CI/CD on AWS does not have to use the Code family. GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Terraform Cloud, and CircleCI are all valid options.

Option	Good for	Watch out for
GitHub Actions	GitHub-centric workflows	Use OIDC to minimize AWS permissions
GitLab CI/CD	Source + CI integrated in GitLab	AWS-side permissioning is separate
Bitbucket Pipelines	Atlassian-aligned stacks	Confirm AWS integration design
CodePipeline + CodeBuild	Want the runtime inside AWS	CodeConnections and IAM design matter
CodeCommit + CodePipeline	Stay fully inside AWS	Collaboration features are lighter than GitHub or GitLab

Amazon CodeCatalyst once bundled source control, issue tracking, and CI/CD into a single managed service. New customer signups stopped on November 7, 2025, so treat it as an option for existing users rather than a default for new builds.

3. Source control and where CodeCommit stands now

3-1. CodeCommit overview

AWS CodeCommit is a managed private Git repository service. The strengths are IAM-driven access control, KMS encryption at rest, TLS in transit, and CloudTrail-based auditing, all controllable from inside AWS.

Item	Detail
Protocols	HTTPS, SSH
Auth	IAM, Git credentials, SSH public key
Encryption	At rest and in transit
Notifications	SNS, Lambda, EventBridge
Integrations	CodeBuild, CodePipeline, CloudTrail
Best fit	Teams that want to keep development inside AWS, regulated industries, IAM-centric governance

3-2. CodeCommit timeline

Date	Event
2024-07-25	New customer access paused
2025-11-24	Full GA return announced
Mid-2026	Safe to put CodeCommit back on the shortlist for new builds

If you migrated to GitHub or GitLab during the pause, you can keep using them. But if you care about staying inside AWS, IAM governance, VPC endpoints, or CloudTrail auditing, CodeCommit is once again a reasonable pick.

3-3. CodeCommit vs GitHub, GitLab, Bitbucket

Lens	CodeCommit	GitHub	GitLab	Bitbucket
AWS integration	Strong	Via CodeConnections	Via CodeConnections	Via CodeConnections
IAM control	Strong	OIDC + GitHub controls	OIDC + GitLab controls	Atlassian controls
Collaboration	Basic	Strong (Issues, Projects, PRs)	Strong (Issue, Board, CI)	Strong Jira integration
CI/CD	Pairs with CodeBuild	GitHub Actions also viable	GitLab CI/CD also viable	Bitbucket Pipelines also viable
Fully inside AWS	Easy	Hard	Hard	Hard

The hands-on in this article uses GitHub. If you prefer CodeCommit, swap the Source action; the CodeBuild, CodeDeploy, and CodePipeline thinking is the same.

3-4. Migrating off CodeCommit

To move history, branches, and tags in one shot, use a mirror clone.

# Mirror-clone the CodeCommit repository
git clone --mirror https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/my-repo temp-repo

# Point the mirror at the empty GitHub repo
cd temp-repo
git remote set-url origin git@github.com:my-org/my-repo.git

# Push every branch and tag
git push --mirror

# Clean up the working directory
cd ..
rm -rf temp-repo

After the move, revisit branch protection, CODEOWNERS, CI/CD configs, webhooks, secrets, and the Source action of every pipeline.

4. GitHub and CodeConnections setup

4-1. Git and SSH key setup

# Configure Git identity
git config --global user.name "your-name"
git config --global user.email "your-email@example.com"

# Default new repositories to main
git config --global init.defaultBranch main

# Generate an SSH key
ssh-keygen -t ed25519 -C "your-email@example.com"

# Verify the connection
ssh -T git@github.com

Create the repository on GitHub and push an initial file to main before moving on.

4-2. Creating the GitHub repository

Keep the demo repository minimal at first, ideally just a README. Reusing the same repo across CodeBuild, CodeDeploy, and CodePipeline makes the end-to-end flow easier to follow.

# Clone the repository
git clone git@github.com:your-name/aws-code-series-demo.git
cd aws-code-series-demo

# Add a starter file
cat > README.md << 'EOF'
# aws-code-series-demo

A demo repository for AWS Code family CI/CD experiments.
EOF

# Commit and push
git add README.md
git commit -m "Add initial README"
git push origin main

Branch protection, required reviews, and required status checks can be layered on later. Start permissive, get the pipeline working, then harden.

4-3. What CodeConnections does

AWS CodeConnections is the bridge between AWS and GitHub, GitLab, Bitbucket, and friends. It was renamed from AWS CodeStar Connections on March 29, 2024.

When you use GitHub in CodePipeline, the Source action typically uses the CodeStarSourceConnection provider. The legacy name lives on in the action, but the service itself is AWS CodeConnections.

Item	Detail
Targets	GitHub, GitHub Enterprise Server, GitLab, Bitbucket, etc.
Role	Detect repo changes and fetch source on AWS' behalf
Required permission	`codeconnections:UseConnection`
Output	ZIP, or a full-clone reference for CodeBuild
Caveat	Some regions restrict the connection action

4-4. Creating and verifying the connection

From the Developer Tools Connections console, pick GitHub, install the GitHub App, and grant access to the target repositories. Once the connection status reads AVAILABLE, the Source action in CodePipeline can use it.

# List your connections
aws codeconnections list-connections \
  --provider-type GitHub \
  --query 'Connections[*].{Name:ConnectionName,Status:ConnectionStatus,Arn:ConnectionArn}' \
  --output table

Older CLI versions and existing resources may still surface the codestar-connections namespace. For new work, design around codeconnections from the start.

5. CodeBuild fundamentals

5-1. What CodeBuild is

AWS CodeBuild is a fully managed build, test, and packaging service. You do not run or maintain build servers.

Trait	Detail
Server management	None
Scaling	Auto-scales with build demand
Runtime	A fresh container per build
Configuration	Declared in `buildspec.yml`
Outputs	S3, ECR, or CodePipeline
Logs	CloudWatch Logs

The default flow is: fetch source, start the environment, run install, pre_build, build, post_build, emit artifacts, tear down.

5-2. Compute types

Type	Trait	Good for
EC2 on-demand	Minute-billed, supports Docker and long builds	General builds
Lambda on-demand	Second-billed, shorter max runtime	Light builds and quick tests
EC2 reserved capacity	Dedicated fleet	High-volume builds, predictable queue times

Docker image builds need EC2 compute with privileged mode enabled. Lambda compute is lightweight but cannot run Docker-in-Docker workloads.

5-3. Pricing at a glance

As of mid-2026, CodeBuild is pay-as-you-go: EC2 on-demand is minute-based, Lambda on-demand is second-based.

Item	Free tier
EC2 on-demand	100 build minutes per month on `general1.small` or `arm1.small`
Lambda on-demand	6,000 build seconds per month on `lambda.arm.1GB` or `lambda.x86-64.1GB`

general1.small will keep this hands-on close to free. CloudWatch Logs, S3, KMS, and ECR are billed separately, so watch those independently.

5-4. Your first CodeBuild project

A minimal setup: a Python app, a test, and buildspec.yml.

# app.py
def hello():
    return "Hello, AWS CodeBuild!"


def add(a, b):
    return a + b


if __name__ == "__main__":
    print(hello())
    print(f"1 + 2 = {add(1, 2)}")

# test_app.py
import unittest
from app import add, hello


class TestApp(unittest.TestCase):
    def test_hello(self):
        self.assertEqual(hello(), "Hello, AWS CodeBuild!")

    def test_add(self):
        self.assertEqual(add(1, 2), 3)
        self.assertEqual(add(-1, 1), 0)


if __name__ == "__main__":
    unittest.main()

When you create the CodeBuild project, you pick the source provider, the GitHub connection, the branch, the runtime, the service role, the buildspec, the artifact target, and the log destination.

5-5. First build and log check

After creating the project, start the first build manually. The goal of run #1 is not "my app works", it is "CodeBuild can fetch the source, read buildspec.yml, and stream logs to CloudWatch Logs".

# Start a build
aws codebuild start-build \
  --project-name code-series-demo-build

# Grab the latest build ID
BUILD_ID=$(aws codebuild list-builds-for-project \
  --project-name code-series-demo-build \
  --query 'ids[0]' \
  --output text)

# Inspect the build state
aws codebuild batch-get-builds \
  --ids "$BUILD_ID" \
  --query 'builds[0].{Status:buildStatus,Start:startTime,End:endTime}'

If it fails, look at Phase details in the CodeBuild console and at CloudWatch Logs. DOWNLOAD_SOURCE_FAILED points at the connection or repo permissions, CLIENT_ERROR usually means a buildspec.yml syntax issue, and UPLOAD_ARTIFACTS_FAILED is almost always S3 permissions.

6. `buildspec.yml` in practice

6-1. Base structure

buildspec.yml declares what CodeBuild runs. Put it at the repository root by default.

version: 0.2

env:
  variables:
    ENVIRONMENT: "dev"

phases:
  install:
    runtime-versions:
      python: 3.12
    commands:
      - echo "Installing dependencies"
      - pip install -r requirements.txt
  pre_build:
    commands:
      - echo "Running tests"
      - python -m unittest discover -v
    finally:
      - echo "pre_build cleanup"
  build:
    commands:
      - echo "Running the application"
      - python app.py
  post_build:
    commands:
      - echo "Build complete"

artifacts:
  files:
    - '**/*'

finally runs even when the phase's commands fail, which makes it a good place for log collection and temp cleanup.

6-2. Environment variables and secrets

Kind	Syntax	Use
Plain environment variable	`env.variables`	Environment name, non-sensitive config
Parameter Store	`env.parameter-store`	API keys, configuration values
Secrets Manager	`env.secrets-manager`	DB passwords, external service credentials
Exported variables	`env.exported-variables`	Pass values to downstream CodePipeline actions

env:
  variables:
    ENVIRONMENT: "production"
  parameter-store:
    API_ENDPOINT: "/app/prod/api-endpoint"
  secrets-manager:
    DB_PASSWORD: "prod/db:password"
  exported-variables:
    - IMAGE_TAG
    - BUILD_VERSION

Never hardcode secrets in buildspec.yml. Pull them from Parameter Store or Secrets Manager. And resist the urge to leave echo $DB_PASSWORD lines in for debugging, they end up in CloudWatch.

6-3. Built-in environment variables

Variable	Contents
`CODEBUILD_BUILD_ID`	Unique build ID
`CODEBUILD_BUILD_NUMBER`	Build number
`CODEBUILD_SOURCE_VERSION`	The requested source version
`CODEBUILD_RESOLVED_SOURCE_VERSION`	Resolved commit hash
`CODEBUILD_SRC_DIR`	Source code directory
`CODEBUILD_WEBHOOK_HEAD_REF`	Branch ref from a webhook trigger

Using a short slice of CODEBUILD_RESOLVED_SOURCE_VERSION as the Docker image tag makes it trivial to trace any artifact back to a commit.

6-4. Cache

Kind	Trait	Caveat
S3 cache	Easy to share across projects	Pays the cost of S3 round-trips
Local cache	Fast on the same host	Cold when the host changes

Local cache supports source cache, Docker layer cache, and custom cache. Docker layer caching requires Linux and privileged mode.

cache:
  paths:
    - '/root/.cache/pip/**/*'
    - 'node_modules/**/*'
    - '/root/.m2/**/*'

6-5. Building Docker images and pushing to ECR

version: 0.2

phases:
  pre_build:
    commands:
      - echo "Logging in to ECR"
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $ECR_REPO
      - IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
  build:
    commands:
      - echo "Building the Docker image"
      - docker build -t $ECR_REPO:$IMAGE_TAG .
      - docker tag $ECR_REPO:$IMAGE_TAG $ECR_REPO:latest
  post_build:
    commands:
      - echo "Pushing the Docker image"
      - docker push $ECR_REPO:$IMAGE_TAG
      - docker push $ECR_REPO:latest
      - printf '[{"name":"app","imageUri":"%s"}]' $ECR_REPO:$IMAGE_TAG > imagedefinitions.json

artifacts:
  files:
    - imagedefinitions.json

Pushing to ECR requires the ECR-related permissions on the CodeBuild service role.

6-6. Batch builds and reports

Batch builds let you run multiple environment combinations in parallel or build a dependency graph of related builds.

Feature	Example
Build matrix	Test on Node.js 20, 22, and 24 in parallel
Build graph	Run unit and integration tests in parallel after the main build
Reports	JUnit XML, Cucumber JSON, TRX, TestNG, NUnit

reports:
  pytest-reports:
    files:
      - 'test-results.xml'
    base-directory: 'reports'
    file-format: JUNITXML

Once test results land as a report, the CodeBuild console gives you pass/fail/skip counts and trend graphs for free.

6-7. Webhook-driven builds

CodeBuild can subscribe to webhooks on its own. Trigger events include push, pull request creation, and pull request updates. Branch and path filters keep useless builds out of the queue.

Filter	Example
Branch	`refs/heads/main`
Pull Request	`PULL_REQUEST_CREATED`, `PULL_REQUEST_UPDATED`
Path	Include `src/`, exclude `docs/`

7. CodeDeploy fundamentals

7-1. What CodeDeploy is

AWS CodeDeploy automates deployments to EC2, on-premises hosts, ECS, and Lambda.

Target	Agent	Common strategies
EC2, on-premises	Required	In-Place, Blue/Green
ECS	Not required	Blue/Green, Canary, Linear, AllAtOnce
Lambda	Not required	Canary, Linear, AllAtOnce

For EC2 and on-prem, the CodeDeploy Agent runs on the instance and executes the steps in appspec.yml.

7-2. Key components

Component	Description
Application	Logical container for a deployable thing
Deployment group	The set of instances or ECS services it targets
Deployment configuration	How many or what percentage to roll at a time
Revision	The deployable artifact
`appspec.yml`	File layout, hooks, and target resources
CodeDeploy Agent	Runs on EC2 or on-prem hosts

7-3. `appspec.yml` for EC2

version: 0.0
os: linux

files:
  - source: /
    destination: /var/www/html

permissions:
  - object: /var/www/html
    owner: apache
    group: apache
    mode: 755
    type:
      - directory

hooks:
  ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 120
      runas: root
  BeforeInstall:
    - location: scripts/install_dependencies.sh
      timeout: 120
      runas: root
  AfterInstall:
    - location: scripts/after_install.sh
      timeout: 120
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 120
      runas: root
  ValidateService:
    - location: scripts/validate_service.sh
      timeout: 120
      runas: root

files defines the destination, permissions sets ownership, and hooks wires lifecycle events to scripts.

7-4. Lifecycle events

An In-Place deployment runs the following events in order:

ApplicationStop
DownloadBundle
BeforeInstall
Install
AfterInstall
ApplicationStart
ValidateService

CodeDeploy handles DownloadBundle and Install itself. The hook scripts you write live in the other events.

8. Deploying to EC2

8-1. Preparing the EC2 side

To deploy with CodeDeploy on EC2, you need an instance role, a CodeDeploy service role, instance tags, and the CodeDeploy Agent.

Item	Detail
EC2 instance role	Permission to fetch revisions from S3, plus SSM permissions
CodeDeploy service role	Permission to read EC2 tags, ASG, and ELB
Tags	Filter to scope which instances are targeted
Agent	The on-host process that executes the deployment

On Amazon Linux 2023, pulling the latest AMI ID from SSM Parameter Store avoids the trap of an AMI ID that quietly goes stale.

AMI_ID=$(aws ssm get-parameters \
  --names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query 'Parameters[0].Value' \
  --output text)

8-2. CodeDeploy Agent

# Fetch the installer
cd /tmp
wget https://aws-codedeploy-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/install

# Install
chmod +x ./install
sudo ./install auto

# Verify
sudo systemctl status codedeploy-agent
sudo codedeploy-agent --version

If the agent is not running, the deployment will not progress. When things go wrong, check /var/log/aws/codedeploy-agent/ and /opt/codedeploy-agent/deployment-root/.

8-3. Deployment file layout

aws-code-series-demo/
├── appspec.yml
├── index.html
└── scripts/
    ├── application_stop.sh
    ├── before_install.sh
    ├── after_install.sh
    ├── application_start.sh
    └── validate_service.sh

#!/bin/bash
echo "Running ValidateService"

sleep 5

HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" http://localhost/)
if [ "$HTTP_CODE" = "200" ]; then
  echo "Validation passed"
  exit 0
else
  echo "Validation failed"
  exit 1
fi

Always include a ValidateService hook. Detecting trouble here is what lets CodeDeploy fail loudly and roll back cleanly.

8-4. Deployment groups

EC2 deployment groups select target instances by tag or by Auto Scaling Group.

Setting	Example
Application name	`code-series-demo-app`
Deployment group name	`code-series-demo-dg`
Deployment type	In-Place
Target	EC2 tag `Name=CodeDeploy-Demo`
Deployment configuration	`CodeDeployDefault.AllAtOnce`
Rollback	Enabled on deployment failure

For production, prefer OneAtATime or Blue/Green over AllAtOnce.

8-5. Running the deployment

Once the CodeDeploy application and deployment group exist, kick off a deployment with a specified revision. With GitHub as the revision source, pass the repo and commit ID. Through CodePipeline, the pipeline hands an S3 artifact to CodeDeploy on your behalf.

# Grab the latest commit ID
git rev-parse HEAD

While the deployment runs, watch the progress through ApplicationStop, DownloadBundle, BeforeInstall, Install, AfterInstall, ApplicationStart, and ValidateService. Once ValidateService passes, visit the EC2 public IP or the ALB DNS name to confirm the app works.

http://<EC2 public IP>/

To try an update, bump a version string in index.html, push, and deploy again. To see what failure looks like, deliberately fail validate_service.sh and watch automatic rollback fire.

9. Deployment strategies and rollback

9-1. In-Place vs Blue/Green

Lens	In-Place	Blue/Green
Approach	Update the existing environment	Spin up a new environment, swap traffic
Downtime	Possible	Largely avoidable
Cost	Low	Temporarily higher
Rollback	Requires a redeploy	Flip traffic back
Pre-test	Hard	Possible via a test listener
Best fit	Dev, small footprints	Production, blast-radius-sensitive workloads

Blue/Green on EC2 leans heavily on load balancer, target group, and Auto Scaling Group design.

9-2. Load balancer integration

For Blue/Green on EC2 with CodeDeploy, the load balancer handles the swap between blue and green. Pair it with an Application Load Balancer or Network Load Balancer.

Element	Role
ALB	Accept HTTP/HTTPS traffic from users
Production listener	Serve normal traffic
Test listener	Verify the new environment before cutover
Target groups	Registered targets for blue and green
Auto Scaling Group	Provisions the green environment

The ALB Blue/Green flow is: build green, verify on the test listener, swap the production listener to green, keep blue around for a while.

Blue
  Currently serving production traffic

Green
  New version deployed, verified on the test listener

Switch
  Repoint the production listener at green

Retain
  Keep blue alive for a window so you can roll back fast

9-3. EC2 deployment configurations

Configuration	Behavior
`CodeDeployDefault.AllAtOnce`	Update all instances at once
`CodeDeployDefault.HalfAtATime`	Update half at a time
`CodeDeployDefault.OneAtATime`	One instance at a time
Custom	Specify minimum healthy hosts as a count or percentage

Production decisions weigh instance count, load balancer, Auto Scaling, and health checks together.

9-4. Automatic rollback

CodeDeploy can roll back automatically on deployment failure or when a CloudWatch alarm fires.

aws cloudwatch put-metric-alarm \
  --alarm-name codedeploy-5xx-alarm \
  --namespace AWS/ApplicationELB \
  --metric-name HTTPCode_Target_5XX_Count \
  --statistic Sum \
  --period 60 \
  --threshold 10 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 2 \
  --treat-missing-data notBreaching

For Blue/Green, hold the old environment for a while instead of decommissioning right away, so cutting back is fast if you need to.

10. Canary deployments to ECS and Lambda

10-1. ECS Blue/Green

With CodeDeploy on ECS the default is Blue/Green. No agent is required. Traffic is swapped via the ALB listener and target groups.

version: 0.0

Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:ap-northeast-1:123456789012:task-definition/my-task:1"
        LoadBalancerInfo:
          ContainerName: "app"
          ContainerPort: 80

Hooks:
  - AfterAllowTestTraffic: "arn:aws:lambda:ap-northeast-1:123456789012:function:ecs-test-hook"

A new task set serves the test listener; after verification, the production listener is swapped over.

10-2. ECS deployment configurations

Configuration	Behavior
`CodeDeployDefault.ECSAllAtOnce`	Cut all traffic at once
`CodeDeployDefault.ECSCanary10Percent5Minutes`	Send 10%, wait 5 minutes, then the rest
`CodeDeployDefault.ECSCanary10Percent15Minutes`	Send 10%, wait 15 minutes, then the rest
`CodeDeployDefault.ECSLinear10PercentEvery1Minutes`	Add 10% every minute
`CodeDeployDefault.ECSLinear10PercentEvery3Minutes`	Add 10% every 3 minutes

With NLB, only CodeDeployDefault.ECSAllAtOnce is supported among the predefined options.

10-3. Lambda deployments

For Lambda, function versions plus an alias let you shift traffic incrementally.

version: 0.0

Resources:
  - myFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: "my-function"
        Alias: "live"
        CurrentVersion: "1"
        TargetVersion: "2"

Hooks:
  - BeforeAllowTraffic: "before-allow-traffic-hook"
  - AfterAllowTraffic: "after-allow-traffic-hook"

Lambda supports AllAtOnce, Canary10Percent variants, and Linear10PercentEvery variants. In production, Canary or Linear is easier to roll out safely while you watch metrics.

10-4. ECS and Lambda hooks

Both ECS and Lambda support Lambda hooks for verification before and after the traffic shift.

Target	Common hook	Use
ECS	`AfterAllowTestTraffic`	Verify the new task set on the test listener
ECS	`BeforeAllowTraffic`	Final pre-cutover check
ECS	`AfterAllowTraffic`	Post-cutover verification
Lambda	`BeforeAllowTraffic`	Pre-traffic-shift check
Lambda	`AfterAllowTraffic`	Post-traffic-shift metric check

Hook functions return success or failure. A failure halts the deployment and triggers rollback per configuration.

11. CodePipeline fundamentals

11-1. What CodePipeline is

AWS CodePipeline orchestrates source, build, test, approval, and deployment as connected stages.

Component	Description
Pipeline	The whole workflow
Stage	Logical grouping like Source, Build, Deploy
Action	A single step inside a stage
Artifact	The thing passed between stages
Transition	The handoff between stages

11-2. Source, build, and deploy providers

Category	Common providers
Source	CodeCommit, GitHub, GitLab, Bitbucket, S3, ECR
Build	CodeBuild, Jenkins
Test	CodeBuild, Manual approval, Lambda Invoke
Deploy	CodeDeploy, CloudFormation, ECS, S3, Elastic Beanstalk, AppConfig
Invoke	Lambda

With GitHub, the Source action references a CodeConnections connection.

11-3. V1 vs V2

Lens	V1	V2
Pricing	Per active pipeline	Per action-minute
Trigger filters	Not supported	Supported
Pipeline-level variables	Not supported	Supported
Git tag triggers	Not supported	Supported
PR, branch, path filters	Not supported	Supported
Stage conditions	Not supported	Supported
Stage rollback	Not supported	Supported

For new pipelines, V2 is the default. For typical workloads running a moderate number of times per month, V2 can also work out cheaper.

11-4. Pricing notes

CodePipeline V1 is billed monthly per active pipeline. V2 is billed per action-minute, excluding manual approvals and custom actions.

Type	Free tier
V1	1 active pipeline per month
V2	100 action-minutes per month

For example, a V2 pipeline that runs Source, Build, and Deploy for 2 minutes each comes out to roughly 6 action-minutes per run. The real billing rounds per action, so always check the latest pricing page for the actual rules.

12. CodePipeline V2 in practice

12-1. Trigger filters

V2 lets you gate connection-based sources (like GitHub) on branch, tag, file path, or pull request conditions.

Filter	Example
Branch	`main`, `release/*`
Tag	Match `v`, exclude `-beta`
File path	Only when `src/**` changes
Pull request	Created, updated, closed

To keep documentation-only changes from triggering production pipelines, exclude docs/** and *.md.

12-2. Pipeline variables

Kind	Example
Pipeline-level variables	`DEPLOY_ENV=staging`
Action output variables	`IMAGE_TAG` from CodeBuild
Namespaced variables	`#{SourceVariables.CommitId}`

To pass values from CodeBuild downstream, use exported-variables.

env:
  exported-variables:
    - IMAGE_TAG

phases:
  build:
    commands:
      - IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - echo "IMAGE_TAG=$IMAGE_TAG"

12-3. Manual approval

Always put a Manual approval action in front of production.

Setting	Detail
SNS notification	Send the approval request to email or chat
Review URL	Link to staging, change set, or dashboard
Comment	Capture reason on approve or reject
Timeout	Up to 7 days

aws codepipeline put-approval-result \
  --pipeline-name my-pipeline \
  --stage-name Approval \
  --action-name ManualApproval \
  --token <approval-token> \
  --result summary="LGTM",status=Approved

12-4. Notifications and EventBridge

CodePipeline state changes flow through EventBridge. Trigger a Lambda on failure, or push to SNS or AWS Chatbot.

aws events put-rule \
  --name codepipeline-failed-rule \
  --event-pattern '{
    "source": ["aws.codepipeline"],
    "detail": {
      "state": ["FAILED"]
    }
  }'

A clean split is SNS for approval-style notifications and EventBridge + Chatbot for pipeline-wide failure alerts.

SNS is well suited to emailing reviewers. For Slack or Microsoft Teams, pair AWS Chatbot with an SNS topic.

# Create an SNS topic
aws sns create-topic \
  --name codepipeline-approval-topic

# Subscribe an email address
aws sns subscribe \
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:codepipeline-approval-topic \
  --protocol email \
  --notification-endpoint reviewer@example.com

12-5. JSON definitions and IaC management

Console-built pipelines can be exported as JSON and version-controlled.

# Export the pipeline definition
aws codepipeline get-pipeline --name my-pipeline > pipeline.json

# Create from JSON
aws codepipeline create-pipeline --cli-input-json file://pipeline.json

# Update an existing pipeline
aws codepipeline update-pipeline --cli-input-json file://pipeline.json

In production, manage the pipeline itself with CloudFormation, CDK, or Terraform.

12-6. From staging to production

Pipelines that touch production deploy to staging first, validate, and then promote.

Source
Build
DeployToStaging
SmokeTest
ManualApproval
DeployToProduction
PostDeployCheck

Pack the manual approval request with everything the reviewer needs: staging URL, change summary, commit ID, CodeBuild test report, CloudFormation change set. The reviewer must be able to answer "what am I approving?".

13. Advanced pipeline design

13-1. Multi-stage layouts

Real pipelines almost never go Build straight to production. Insert multiple stages.

Source
Build
UnitTest
IntegrationTest
DeployToStaging
Approval
DeployToProduction

Separating responsibilities makes failures easy to localize.

13-2. Parallel actions

Within a stage, actions with the same runOrder run in parallel.

runOrder 1: UnitTest, Lint, SecurityScan
runOrder 2: SmokeTest

Parallelizing tests cuts wall-clock time. When actions have artifact dependencies, split them across runOrder values.

13-3. Multiple sources and artifacts

When the front end and back end, or the app and infra, live in separate repos, use multiple Source actions.

version: 0.2

phases:
  build:
    commands:
      - echo "Main source is at $CODEBUILD_SRC_DIR"
      - echo "Infra source is at $CODEBUILD_SRC_DIR_infra"

artifacts:
  secondary-artifacts:
    app-artifact:
      files:
        - '**/*'
      base-directory: dist
    cfn-artifact:
      files:
        - '**/*'
      base-directory: infra

Name artifacts clearly. Downstream actions will reference them.

13-4. CloudFormation integration

CodePipeline supports a CloudFormation deploy action.

Action mode	Use
`CREATE_UPDATE`	Create or update a stack directly
`DELETE_ONLY`	Delete a stack
`REPLACE_ON_FAILURE`	Replace a failed stack
`CHANGE_SET_CREATE`	Create a change set
`CHANGE_SET_EXECUTE`	Execute a change set

For safe production rollouts, do CHANGE_SET_CREATE, then manual approval, then CHANGE_SET_EXECUTE.

AWSTemplateFormatVersion: "2010-09-09"
Description: Simple S3 bucket for the CodePipeline demo

Resources:
  DemoBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

Running CloudFormation directly is fine, but the change-set-then-approve-then-execute pattern is safer for production.

13-5. Cross-account deployment

When the dev account's CodePipeline deploys into a production account, design S3, KMS, AssumeRole, and the target-service permissions across accounts.

Element	Setup
Dev account S3	Allow access from the production role
Dev account KMS	Grant decrypt to the production role
Production account IAM	Role assumable by CodePipeline
Production account targets	CodeDeploy, CloudFormation, ECS, etc.

Set roleArn on the Deploy action in the production account to point at the cross-account role.

13-6. Cross-region and Lambda Invoke

For cross-region deployments, set region on the action. Each region needs its own artifact store.

Lambda Invoke actions are great for Slack notifications, DB migrations, external API calls, and pre-deploy checks.

import boto3

codepipeline = boto3.client("codepipeline")


def lambda_handler(event, context):
    job_id = event["CodePipeline.job"]["id"]

    try:
        # Custom logic goes here
        codepipeline.put_job_success_result(jobId=job_id)
    except Exception as exc:
        codepipeline.put_job_failure_result(
            jobId=job_id,
            failureDetails={
                "type": "JobFailed",
                "message": str(exc)
            }
        )

Always send either success or failure back to CodePipeline. Without it, the action waits until it times out.

14. Building a CI/CD pipeline from scratch

14-1. The setup

The reference setup in this article uses GitHub, CodePipeline V2, CodeBuild, CodeDeploy, and EC2.

flowchart LR
    G[GitHub] --> P[CodePipeline V2]
    P --> S[Source]
    S --> B[CodeBuild]
    B --> D[CodeDeploy]
    D --> E[EC2 Apache]
    B --> A[(S3 Artifacts)]

14-2. Resources you will create

Category	Resources
Source	GitHub repo, CodeConnections
Build	CodeBuild project, CloudWatch Logs
Artifacts	S3 artifact bucket
Deploy	CodeDeploy application, deployment group
Runtime	EC2, security group, IAM instance profile
Orchestration	CodePipeline V2
Permissions	EC2, CodeBuild, CodeDeploy, CodePipeline roles

14-3. Repository layout

aws-code-series-handson/
├── buildspec.yml
├── appspec.yml
├── index.html
├── css/
│   └── style.css
├── js/
│   └── app.js
├── tests/
│   └── test_app.sh
└── scripts/
    ├── install_dependencies.sh
    ├── stop_server.sh
    ├── start_server.sh
    └── validate_service.sh

buildspec.yml runs the tests and emits the artifact for CodePipeline. appspec.yml defines the on-EC2 layout and lifecycle scripts.

14-4. `buildspec.yml`

version: 0.2

phases:
  install:
    commands:
      - echo "Preparing dependencies"
      - chmod +x tests/test_app.sh
      - chmod +x scripts/*.sh
  pre_build:
    commands:
      - echo "Running tests"
      - ./tests/test_app.sh
  build:
    commands:
      - echo "Producing artifacts"
  post_build:
    commands:
      - echo "Build complete"

artifacts:
  files:
    - '**/*'

14-5. `appspec.yml`

version: 0.0
os: linux

files:
  - source: /
    destination: /var/www/html

hooks:
  BeforeInstall:
    - location: scripts/install_dependencies.sh
      timeout: 300
      runas: root
  ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 300
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 300
      runas: root
  ValidateService:
    - location: scripts/validate_service.sh
      timeout: 300
      runas: root

14-6. Validating the flow

Scenario	Expected result
Healthy commit	Source, Build, Deploy all succeed after push
Failed test	Build halts, no Deploy
Failed deploy	Deploy fails, rollback if configured
Manual re-run	`start-pipeline-execution` re-triggers
Stage retry	Retry only the failed stage

# Check pipeline state
aws codepipeline get-pipeline-state \
  --name code-series-demo-pipeline \
  --query 'stageStates[*].{Stage:stageName,Status:latestExecution.status}'

# Manual run
aws codepipeline start-pipeline-execution \
  --name code-series-demo-pipeline

# Retry only the failed actions
aws codepipeline retry-stage-execution \
  --pipeline-name code-series-demo-pipeline \
  --stage-name Deploy \
  --pipeline-execution-id <execution-id> \
  --retry-mode FAILED_ACTIONS

14-7. Cleanup

Wrong delete order will leave you blocked by dependencies.

CodePipeline
CodeDeploy deployment group
CodeDeploy application
CodeBuild project
EC2 instance
Security group
S3 bucket objects
S3 bucket
IAM instance profile
IAM role
CodeConnections connection

Empty the S3 bucket before deleting it. Detach the IAM role from the instance profile before deleting the role.

15. Security and IAM design

15-1. CI/CD security layers

flowchart TB
    A[IAM and authentication] --> B[Secrets management]
    B --> C[S3 and KMS encryption]
    C --> D[VPC and network controls]
    D --> E[CloudTrail and CloudWatch]

A CI/CD pipeline is a privileged path into production, so it deserves the same level of protection as the application itself.

15-2. Service role design

Role	Required	Avoid
CodeBuild	S3, CloudWatch Logs, ECR when needed	Admin permissions, unneeded EC2 access
CodeDeploy	EC2 tag read, ELB, ASG, S3 read	EC2 create or delete
CodePipeline	CodeBuild start, CodeDeploy start, S3, CodeConnections	Direct server operations
EC2	Fetch revisions from S3, SSM	Admin permissions

It is tempting to start broad. Just make sure you tighten down after things work.

15-3. A CodeBuild custom policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudWatchLogs",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/codebuild/*"
    },
    {
      "Sid": "S3Artifacts",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::my-artifact-bucket",
        "arn:aws:s3:::my-artifact-bucket/*"
      ]
    }
  ]
}

For ECR pushes, add ecr:GetAuthorizationToken, ecr:BatchCheckLayerAvailability, ecr:InitiateLayerUpload, ecr:UploadLayerPart, ecr:CompleteLayerUpload, and ecr:PutImage.

15-4. Secrets management

Approach	Good for	Watch out for
Plain environment variables	Non-sensitive settings	Never use for secrets
SSM Parameter Store	API keys, per-environment values	Use SecureString
Secrets Manager	DB credentials	Account for cost and rotation
KMS	Encryption keys	Lock down key policies

CI/CD logs live longer than you think. Never let secrets land in build logs, and watch out for failure-time debug output too.

15-5. Encrypting the artifact bucket

aws s3api put-bucket-encryption \
  --bucket my-artifact-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms"
      },
      "BucketKeyEnabled": true
    }]
  }'

Force HTTPS, block unintended public access, and for cross-account use, do not forget the KMS key policy.

16. Cost, monitoring, and logs

16-1. Cost levers

Target	Optimization
CodeBuild	Cache, right-size compute, set timeouts
CodePipeline V2	Branch, tag, and path filters to skip useless runs
CodeDeploy	Spin verification EC2 only when needed
S3	Lifecycle rules for old artifacts
CloudWatch Logs	Configure retention
KMS	Avoid an exploding key count

For V2, every avoided execution is direct cost savings. Excluding docs/** and README changes from production pipelines pays for itself fast.

16-2. Metrics to watch

Service	Watch
CodeBuild	Build failures, build duration, queue wait
CodeDeploy	Deployment failures, rollback counts
CodePipeline	Pipeline failures, stage failures, pending approvals
EC2, ALB	5xx, latency, target health
S3	Artifact bucket usage

For production, alert on even one CodePipeline or CodeDeploy failure.

16-3. Where logs live

Service	Location
CodeBuild	CloudWatch Logs `/aws/codebuild/<project>`
CodeDeploy Agent	`/var/log/aws/codedeploy-agent/`
CodeDeploy deployment	`/opt/codedeploy-agent/deployment-root/`
CodePipeline	CloudTrail, EventBridge, console history

CloudWatch Logs Insights makes failure searches easy.

fields @timestamp, @message
| filter @message like /ERROR|FAIL|Exception/
| sort @timestamp desc
| limit 50

16-4. Cost monitoring

Set up AWS Budgets to track CodeBuild, CodePipeline, S3, CloudWatch Logs, and KMS spend. The classic hands-on cost traps are forgotten EC2 instances, S3 buckets, CloudWatch Logs, and ECR images.

17. Troubleshooting

17-1. CodeBuild

Error	Cause	Fix
`DOWNLOAD_SOURCE_FAILED`	GitHub connection or repo permission	Check the CodeConnections status
`CLIENT_ERROR`	`buildspec.yml` syntax	Look for YAML, indentation, and tab issues
`BUILD_FAILED`	Test failure or missing dependency	Read CloudWatch Logs
`UPLOAD_ARTIFACTS_FAILED`	Insufficient S3 permissions	Check the CodeBuild role's S3 access
Docker daemon error	Missing privileged mode	Enable Privileged mode
Out of memory	Compute too small	Bump compute size or split tests

17-2. CodeDeploy

Error	Cause	Fix
Agent unresponsive	Agent stopped or not installed	`systemctl status codedeploy-agent`
`ScriptFailed`	Hook script failure	Read logs under `deployment-root`
`ScriptTimedOut`	Timeout too short, or hung process	Extend timeout or fix the script
`HEALTH_CONSTRAINTS`	Not enough healthy instances	Recheck deployment config and health checks
S3 403	EC2 role lacks S3 access	Check role permissions and bucket policy
First-deploy ApplicationStop fails	No previous revision	Often expected on the first run

17-3. CodePipeline

Error	Cause	Fix
Source failed	GitHub connection or repo permission	Recheck CodeConnections
Build failed	CodeBuild-side failure	Read CodeBuild logs
Deploy failed	`appspec`, agent, or permission issue	Read CodeDeploy logs
Insufficient permissions	Service role too narrow	Check the CodePipeline role
Action configuration error	Action misconfigured	Check provider, artifact, and region

17-4. CLI you will use a lot

# Block transitions into the Deploy stage
aws codepipeline disable-stage-transition \
  --pipeline-name my-pipeline \
  --stage-name Deploy \
  --transition-type Inbound \
  --reason "Maintenance"

# Re-enable transitions
aws codepipeline enable-stage-transition \
  --pipeline-name my-pipeline \
  --stage-name Deploy \
  --transition-type Inbound

# Re-run with a specific commit
aws codepipeline start-pipeline-execution \
  --name my-pipeline \
  --source-revisions actionName=Source,revisionType=COMMIT_ID,revisionValue=abc1234

18. Patterns and team practices

18-1. Pipeline design patterns

Pattern	Good for
Single branch	Solo work, small experiments
Branch-based	Typical team development
Multi-account	Organizations that isolate production permissions
Microservice-per-pipeline	Independently releasable services

A branch-based layout is the easiest starting point.

feature/*
  Run tests only on pull requests

develop
  Auto-deploy to dev

main
  Auto-deploy to staging
  Manual approval, then auto-deploy to production

release/*
  Lock release candidates and verify

18-2. Team rules

Rule	Detail
`main` protection	No direct push, PR required
Review	At least one approval
Tests	Required checks must pass before merge
Production approval	Manual approval in CodePipeline
Rollback	Documented procedure and on-call owner
Naming convention	`<env>-<service>-<purpose>-pipeline`
Tagging	`Project`, `Environment`, `Owner`, `CostCenter`

18-3. Incident response flow

Alert detected
Assess blast radius
Identify root cause
Roll back or pause the pipeline
Apply a workaround
Apply the real fix
Postmortem

When a pipeline fails, do not stop at "fix the failure". Cover detection, notification, rollback, and prevention.

18-4. Pre-flight checklist

Lens	Check
Source	CodeCommit or GitHub, connection method decided
Build	`buildspec.yml` defines tests and artifacts
Deploy	`appspec.yml` and hooks are organized
Pipeline	V2, trigger filters, manual approval considered
Rollback	CodeDeploy paired with a CloudWatch alarm
Permissions	Every service role minimized
Secrets	Stored in Parameter Store or Secrets Manager
Monitoring	EventBridge, SNS, Chatbot, CloudWatch wired up
Cost	Wasted runs, log retention, S3 residue under control
Operations	Naming, tagging, incident response, cleanup defined

Wrap-up

Thanks for reading this far.

Looked at one at a time, the AWS Code family is a collection of fairly modest services. CodeCommit handles source. CodeBuild builds. CodeDeploy deploys. CodePipeline glues them together.

The real value shows up when you combine them. A push triggers tests, an artifact is stored, staging gets updated, an approver signs off, production receives the change, failures stop the train, and logs let you find the root cause. Once all of that holds together, CI/CD stops being "nice automation" and becomes "a safe way to release".

As of 2026, CodeCommit's return to GA puts the "fully inside AWS" option back on the table. Pairing GitHub or GitLab with CodeBuild, CodeDeploy, and CodePipeline as the AWS-side runtime is also still very much a real choice.

What matters more than service selection is the shape of the flow: small changes, automated verification, deliberate approval, deliberate rollback, and a system you can learn from when it fails.

See you in the next one.

About this article

This article is the English adaptation of a Japanese post I originally wrote on Qiita, a developer community popular in Japan.

https://qiita.com/miruky/items/REPLACE_WITH_QIITA_ID

References

AWS Code family official docs

Connections, adjacent services, and operations

A Roundup of Engineering “Laws” from the English-Speaking World That Are Surprisingly Well-Known in Japan

miruky — Thu, 21 May 2026 14:28:56 +0000

Introduction

Hi, I'm miruky.

Over a recent long weekend, I went out for drinks with an older friend from high school who works as a tech lead. We ended up talking about a project of his that had recently gone sideways, and at some point he said something like, "honestly, it was a textbook case of Brooks's Law." I had seen the term in a book before, but, embarrassingly enough, I could not quite recall what it actually meant.

This is not just about Brooks's Law. There is a long list of "the Law of X", "the X Principle", and "the X Effect" that every engineer seems to know. Other professions have their own proverbs and rules of thumb, but our field is unusually fond of inventing them. Probably some of it comes from English-speaking software culture, which has always enjoyed naming patterns.

A few off the top of my head: Brooks's Law, Conway's Law, Hyrum's Law, the Joshua Tree Principle, Stone Soup, the Boiling Frog, reinventing the wheel, yak shaving, and so on.

You can absolutely live without memorizing any of these, but I want to keep them within reach, both as a piece of engineering literacy and as a personal commitment to not repeat past mistakes. Some of them genuinely earn their keep during code review. So in this article, I am organizing the famous ones, each with a short definition and a note on when it actually matters in practice. Treat it as a personal cheatsheet.

A note on scope

This article prioritizes "do engineers actually use this in conversation?" and "does it show up in classic software engineering literature?" over strict academic accuracy. More obscure terms are intentionally omitted.

Laws
Other principles, strategies, and metaphors
How to use these terms

1. Laws

The star rating is my own rough sense of "how often this term actually comes up in engineering conversations and code reviews". It is not a strict ranking, just a feel for how often it shows up in technical writing, design discussions, and pull request reviews.

Stars	Meaning
★★★★★	5 stars. Heard often in conversation and code review
★★★★☆	4 stars. Common knowledge; comes up in design discussions and small talk
★★★☆☆	3 stars. Known by some, but less frequent in day-to-day talk
★★☆☆☆	2 stars. Appears in books and classics, less so in conversation
★☆☆☆☆	1 star. Fairly obscure; barely used in this article

First, the ones that are most commonly framed as "laws" in everyday software development.

1-1. Project and organization laws

Conway's Law ★★★★☆

The structure of a system tends to mirror the communication structure of the organization that built it.

If your auth team, payments team, and inventory team never talk to each other, you should not be surprised when that disconnect shows up in your API boundaries and your screen transitions. It looks like an architecture conversation, but a lot of the time it is really an org design conversation. The term shows up constantly in discussions of microservice boundaries, team splits, and responsibility lines.

Brooks's Law ★★★★☆

Adding people to a late software project can make it even later.

This is not the simple "do not add people, ever" rule it is sometimes flattened into. The point is that onboarding, alignment, reviews, merges, and decision coordination all grow with team size, so dropping new people into a burning project does not produce instant relief. It is the standard warning you hear before someone proposes "let's just throw more headcount at it."

Parkinson's Law ★★★★☆

Work expands so as to fill the time available for its completion.

If the deadline is a week, the work takes a week. If it is a month, it takes a month. Meetings behave the same way: a 30-minute agenda will happily absorb a 60-minute slot. This is the reason short deadlines, short review windows, and short meetings tend to be a good default. It is the same reason summer break homework somehow always gets finished only in the last few days, no matter how much time you started with.

Ninety-Ninety Rule ★★★☆☆

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

This one is attributed to Tom Cargill at Bell Labs and is also quoted in Jon Bentley's Programming Pearls. The punchline is that the numbers sum to 180%. It is a tidy explanation of why "we're basically done, just a few tweaks left" is rarely trustworthy. The final edge cases, error handling, documentation, tests, and operational work tend to be heavier than anyone estimated.

Parkinson's Law of Triviality (Bikeshedding) ★★★☆☆

People tend to spend disproportionate time on small, easy-to-grasp problems rather than on the important and difficult ones.

The classic example is a committee that breezes past the design of a nuclear reactor but argues for hours about the color of the bike shed. In engineering, this shows up as architecture decisions getting waved through while a code review stalls on a variable name, a button color, or microscopic copy choices.

Peter Principle ★★★☆☆

People tend to be promoted until they reach a position where they are no longer effective, and then stay there.

Promoting your strongest developer to manager does not automatically produce your strongest manager. Being great at writing code and being great at hiring, evaluating, shaping teams, and negotiating budgets are different skills. Worth keeping in mind whenever you are thinking about engineering manager or tech lead role design.

Hofstadter's Law ★★☆☆☆

It always takes longer than you expect, even when you take into account Hofstadter's Law.

This one self-references on purpose. It lands during estimation, release planning, migrations, and legacy rewrites: "I padded the estimate this time, and even with that, we still ran out of time." A short, accurate description of how schedules actually behave.

1-2. Design and code laws

Postel's Law ★★★★☆

Be conservative in what you send, be liberal in what you accept. Also known as the Robustness Principle, from early TCP/IP RFCs.

In the early internet, this kind of tolerance helped systems interoperate. In modern web and security contexts, being too liberal in what you accept can mean fuzzy specs and exploitable corners, so "do not be too lenient on input" is also part of the conversation now. Input validation usually wants the opposite of pure tolerance.

Law of Demeter ★★★★☆

An object should only talk to its immediate neighbors. Also known as the Principle of Least Knowledge.

Long chains like user.getCompany().getAddress().getZip() quietly couple the caller to the internal structure of every object in the chain. The moment any of those internals change, the call site breaks. This law shows up in class design, domain modeling, and API design.

Law of Leaky Abstractions ★★★★☆

All non-trivial abstractions, to some degree, leak.

Using an ORM does not let you forget about SQL. Using the cloud does not let you forget about networking and IAM. Using React or Next.js does not free you from how the browser actually works. Abstractions are convenient, but the layer underneath never fully disappears.

Kernighan's Law ★★★★☆

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

A direct shot at one-liners, nested ternaries, gratuitous metaprogramming, and clever abstractions that read like riddles. Code is judged not by "can I write this?" but by "can I still read this in three months?" and "can I still fix this when it breaks at 2am?"

Atwood's Law ★★★★☆

Any application that can be written in JavaScript will eventually be written in JavaScript.

A neat summary of how web technologies have escaped the browser into the server, the desktop, mobile, the CLI, and IoT. If you have spent any time in the Electron / Node.js / React Native part of the world, this one writes itself.

Hyrum's Law ★★★☆☆

With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody.

Anyone who has ever shipped a public API has lived through this. The accidental key order in a response, an error message that happens to be stable, a request that happens to complete in a predictable amount of time: even when none of that is part of the documented contract, somebody will end up depending on it. Anything visible can become a contract.

Linus's Law ★★★☆☆

Given enough eyeballs, all bugs are shallow. The phrase was coined by Eric S. Raymond in The Cathedral and the Bazaar and named in tribute to Linus Torvalds's development model, not by Linus himself.

Roughly: with enough people looking at the code, bugs get found and root-caused faster. Useful when explaining the value of code review, open source, audits, and bug bounties. The catch is that headcount alone does not buy safety; reviewers need relevant expertise, code needs to be reviewable, and you need tests and reproducible builds to back any of it up.

Zawinski's Law ★★☆☆☆

Every program attempts to expand until it can read mail.

The serious version: useful tools accumulate features until they have quietly become full platforms. The tiny task tracker grows a chat tab, then a calendar, then mail, then AI, then workflows.

Sturgeon's Law ★★☆☆☆

Ninety percent of everything is crap.

Bluntly useful when evaluating libraries, sample code, blog posts, OSS projects, or AI-generated code. The job is not to admire everything that exists, but to develop an eye for the worthwhile 10%.

1-3. Performance and scale laws

Moore's Law ★★★★☆

Transistor density on integrated circuits has doubled at a roughly constant cadence.

Originally a prediction about component count on a chip, later stretched into a broader story about ever-increasing compute. Physical limits and manufacturing costs have made the simple version harder to maintain, so the current reality is more nuanced than the classic framing.

Amdahl's Law ★★★★☆

The speedup you get from parallelizing a program is limited by the part that cannot be parallelized.

A cold shower for "just add more servers and it will be faster." If the bottleneck is a DB lock, a single queue, an external API, or some synchronous step in the middle, more workers will not save you past a certain point. It is the standard mental model when discussing multithreading, distributed processing, and host-side overhead in GPU workloads.

Wirth's Law ★★★☆☆

Software gets slower faster than hardware gets faster.

Hardware keeps improving, and yet perceived speed often does not, thanks to ballooning dependencies, more abstraction layers, Electron-everything, and an endless stream of new features. Comes up whenever someone is talking about performance work or trimming bloat.

Metcalfe's Law ★★★☆☆

The value of a network grows roughly with the square of the number of its users.

With n participants, the number of possible pairs is n(n-1)/2, which scales close to n² for large n. That is the basis for the "value proportional to the square of users" framing. Common in explanations of social networks, marketplaces, telecom networks, and developer communities.

Gustafson's Law ★★☆☆☆

If you can grow the problem with the machine, parallelization pays off more than Amdahl suggests.

Amdahl's Law asks "how fast can I make a fixed workload?". Gustafson's Law asks "now that I have more compute, how much bigger a problem can I tackle?". You see it most often in HPC, batch processing, and large-scale data work.

1-4. Metrics and decision laws

Pareto Principle (80/20 Rule) ★★★★★

A small share of causes is responsible for a large share of the outcomes. Famous well outside engineering.

Most incidents tend to cluster in a few features. Most support tickets tend to cluster on a few screens. Most revenue tends to come from a few customers. Handy when prioritizing critical bugs, key users, and recurring support themes.

Murphy's Law ★★★★★

The compact version: anything that can go wrong, will go wrong.

In practice, this is not "expect doom" but "stop assuming nothing will fail, and start designing for what happens when it does". It is the friendly companion of failure design, retries, monitoring, backups, idempotency, and fail-safe defaults. The classic illustration is the slice of buttered toast that, when knocked off the table, lands butter-side down.

Goodhart's Law ★★★★☆

When a measure becomes a target, it ceases to be a good measure. The pithy form is usually credited to Marilyn Strathern's restatement.

Make test coverage a target and you get tests that exist mostly to lift the number. Make velocity a performance metric and ticket splitting becomes a game. Make incident count a goal and small incidents stop getting reported. Metrics are useful as signals, but they get corrupted the moment they become objectives in themselves.

Gall's Law ★★★☆☆

A complex system that works is invariably found to have evolved from a simple system that worked.

Starting from a giant ideal architecture rarely beats starting from something small that works and then growing it. The principle bites hard on new products, big replatform projects, and platform overhauls.

Campbell's Law ★★☆☆☆

The more any quantitative indicator is used for decision-making, the more it tends to distort and corrupt the processes it is intended to monitor.

A close cousin of Goodhart's Law, more often cited in evaluation, education, and policy contexts. In engineering organizations, tying compensation directly to PR count, commit count, story points, or review count tends to produce predictable distortion.

2. Other principles, strategies, and metaphors

This second group is not strictly "laws", but it includes principles, strategies, indicators, metaphors, and phrases from classic books that show up constantly in engineering conversations.

2-1. Design principles

DRY ★★★★★

I have been called out on this in real code review. Short for Don't Repeat Yourself: do not duplicate the same piece of knowledge in multiple places.

It is often misread as "do not write the same line twice." The thing you really must not duplicate is knowledge: business rules, constants, schemas, specifications. Forcing two coincidentally similar chunks of code into a single shared abstraction tends to backfire when the two reasons for change start diverging. The Pragmatic Programmer is the canonical reference.

KISS ★★★★★

Short for Keep It Simple, Stupid: prefer the simplest design that solves the problem.

This shows up in design, API shape, runbooks, and team rules. Choose a structure you can read, explain, and recover from when it breaks, over one that merely looks clever. Simple really is best, more often than not.

YAGNI ★★★★★

Short for You Aren't Gonna Need It: do not build features you do not need yet. An Extreme Programming staple.

This is not "ignore the future." It is "do not pay today's cost for tomorrow's hypothetical." A surprising amount of code written "just in case" never gets used in the form you imagined.

SOLID ★★★★★

A mnemonic for five object-oriented design principles.

Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. SOLID gets some legitimate criticism in modern contexts, but as a shared vocabulary for talking about dependencies, reasons for change, and responsibility boundaries, it is still very much in use.

Single Responsibility Principle ★★★★★

I hear this one a lot. A module or a class should have only one reason to change.

It does not mean "one method per class." If changes to your user view, your billing rules, and your DB storage format all flow through the same class, that class is probably doing too much.

Separation of Concerns ★★★★★

Do not blend unrelated concerns into the same place.

When UI, domain logic, DB access, auth, logging, notifications, and external API calls all live tangled together, every change becomes scary. This is the idea sitting under layered architecture, clean architecture, and MVC.

Principle of Least Privilege ★★★★★

Genuinely essential. Grant only the minimum privileges required.

Applies broadly: IAM, DB permissions, CI/CD, GitHub Actions, AI agents, MCP tools, admin dashboards, the lot. The default is not "open it up until people stop complaining", but "figure out the smallest scope that works and hand out exactly that."

Open-Closed Principle ★★★★☆

Software entities should be open for extension, but closed for modification.

The goal is to add a new payment method or a new notification target without rewriting half the existing code. Pushed too far it produces an abstraction graveyard, so it needs to live in tension with YAGNI.

Principle of Least Astonishment ★★★★☆

Behave in a way that does not surprise the user.

Applies to function names, API responses, UI, default values, and CLI flags. A function called deleteUser() that actually performs a hard delete when the rest of the system uses soft deletes, or a get endpoint that mutates the database, will surprise people. Surprise is a bug.

Unix Philosophy ★★★★☆

Build small tools, make them compose well.

The familiar slogans, "do one thing and do it well", "communicate via text streams", "compose small tools", come from Unix culture. The influence is clearly visible in CLIs, pipes, microservices, and modern developer tooling.

WET ★★☆☆☆

The anti-DRY: variously expanded as Write Everything Twice, Write Every Time, or We Enjoy Typing. It describes a bad state.

You end up with the same logic, the same rule, or the same configuration scattered across the codebase. When the spec changes, you fix one copy and forget the other; docs drift away from the code; tests still assert the old behavior. The DRY / WET pairing is one of the more fun bits of vocabulary in the field.

ETC (Easier to Change) ★★☆☆☆

A guiding value from The Pragmatic Programmer (20th anniversary edition): make code easier to change.

The book explicitly frames ETC as a value, not a rule. DRY, KISS, YAGNI, and Separation of Concerns can all be read as instances of "will this make the next change easier or harder?". When you are stuck between two designs, asking that question often unblocks the decision.

2-2. Methods and metaphors from classic books

Prototype ★★★★★

Code you write specifically to learn, with the expectation of throwing it away.

Useful for de-risking an unfamiliar technology, a UI direction, a library, or a performance profile. The danger is conflating "things I am going to grow into production code" with "things I am going to throw away." Code written to be thrown away has a nasty habit of being shipped instead.

Reinventing the Wheel ★★★★★

You hear this constantly. Rebuilding something that already exists, for no good reason.

Standard examples include writing your own framework or, worse, your own crypto without checking the existing ecosystem first. A clear caveat: rebuilding something for learning purposes, or to satisfy a constraint that no off-the-shelf option supports, can be valuable. The problem is ignoring existing knowledge and repeating other people's mistakes.

Boiling Frog ★★★★☆

When conditions worsen slowly, people tend to miss the danger. The Pragmatic Programmer introduces it alongside Stone Soup.

The story (a frog in slowly heating water failing to notice the danger) is used as a metaphor for slow decay. Builds get one minute slower. Tests get slightly flakier. A few more type errors get ignored. Each step is small enough to overlook, but the cumulative effect is a much slower team. This is the shape of technical debt. The biological version is not actually accurate; treat it strictly as a software-engineering metaphor.

Broken Windows Theory ★★★★☆

If you tolerate small messes, larger messes follow. Famous outside engineering as well.

In code: failing tests, sloppy naming, abandoned TODOs, unformatted files, perpetually red CI. Letting these sit broadcasts the message "this repo is fine to treat carelessly," which then attracts more carelessness.

Rubber Duck Debugging ★★★★☆

Explain the problem out loud and you often spot the bug yourself.

The audience does not have to be human. A rubber duck on your desk works fine. Walking through the code line by line forces you to confront the gaps in your own understanding, which makes it useful as a pre-review self-check too.

No Silver Bullet ★★★★☆

There is no single technology that can deliver a tenfold productivity improvement to software development on its own. Frederick Brooks's famous argument.

New languages, frameworks, clouds, and AI tools do not erase the essential difficulties of understanding requirements, managing complexity, accommodating change, and communicating with people. A handy phrase for tempering hype around new technology. ("Silver bullet" here is the folkloric weapon that kills monsters in one shot.)

Yak Shaving ★★★★☆

Doing a chain of prerequisite tasks before you can get to the thing you actually wanted to do.

"I just wanted to fix this small bug, but to run the tests I had to upgrade Node, and to upgrade Node I had to fix CI, and to fix CI I had to revisit permissions, and now I have no idea what I was originally doing." Very common during environment setup and dependency upgrades.

Stone Soup ★★★☆☆

A metaphor for kickstarting a small change that ends up pulling other people in.

The folk tale: a traveler offers to make a soup from a stone, sets up a pot, and asks each villager to contribute one small ingredient. By the end, there is a real soup.

In a codebase, the equivalent is something like: "Let's refactor the whole module" goes nowhere, but a small, concrete improvement PR ships. Someone else sees it and adds tests. Someone else adds docs. Before long, an improvement effort exists.

Tracer Bullets ★★★☆☆

Cut a thin slice all the way through the system, end to end, as your first real implementation.

The metaphor is borrowed from tracer rounds in ballistics: rounds that glow in flight so you can correct your aim in real time.

This is not the same as a throwaway prototype. The tracer-bullet slice is meant to be real, just narrow: UI, API, DB, deploy, and monitoring, all wired up at the smallest viable scope, then widened over time. It overlaps with the idea of a "walking skeleton."

The difference from a prototype is intent. A prototype is meant to be thrown away. A tracer-bullet slice is meant to be kept and grown. Both are tools for fast feedback, but they live different lives.

2-3. Cognition and learning metaphors

Joshua Tree Principle ★★★★★

This one resonates with me. Once you learn the name of a thing, you start noticing it everywhere.

Not so much an academic law as a metaphor that gets phrased as the Joshua Tree principle or Joshua Tree epiphany. Learn the name "Hyrum's Law", and you start spotting "uh-oh, somebody is going to depend on this exact behavior" during API review. Design patterns, anti-patterns, incident patterns, and cognitive biases all become much easier to spot once you have a label for them.

Dunning-Kruger Effect ★★★★☆

People with low ability in a domain tend to overestimate their ability.

The pop version is "beginners are overconfident", but the real claim is subtler: the metacognitive skill needed to notice your own mistakes is one of the things you are missing in the first place. There is a clear parallel with over-trusting AI-generated code. In any unfamiliar area, hold back on certainty and insist on verification and review.

Confirmation Bias ★★★★☆

The tendency to seek and weigh information that fits the hypothesis you already hold.

In incident response, deciding "this is a DB problem" makes you read every log through DB-colored glasses. The same thing happens during performance tuning and code review. Forming a hypothesis is fine; the discipline is to also look for the evidence that would refute it.

Occam's Razor ★★★★☆

Among competing explanations of equal predictive power, prefer the one with fewer assumptions.

Named after the 14th-century philosopher and theologian William of Ockham. The original "do not multiply entities beyond necessity" is often described as shaving away unnecessary assumptions with a razor.

In incident response, before reaching for an exotic distributed-systems bug, check the boring options first: a misconfiguration, a missing env var, a forgotten deploy, an unusual input, a time-zone bug. The simple explanation is not always right, but it is a strong opening hypothesis.

Chesterton's Fence ★★★★☆

Do not remove a fence you do not understand the purpose of, until you understand its purpose.

The image, from G.K. Chesterton, is of someone walking down a road and finding a fence that seems pointless. The first move is not "tear it down because it serves no use", but "find out why it was built in the first place."

In legacy code, when you find a strange if branch or a baffling config switch, it is tempting to delete it on sight. But it may be the residue of a real production incident, a customer-specific requirement, or a regression workaround. Check logs, issues, commit history, and other engineers' memory before removing it.

Survivorship Bias ★★★☆☆

Drawing conclusions only from the cases that survived to be visible.

Studying only successful startups, popular OSS, and viral blog posts will quietly convince you that "doing X is the path to success." What is missing from view is the much larger pile of efforts that did the same thing and failed. Worth holding in mind during tech selection and career conversations.

Baader-Meinhof Phenomenon (Frequency Illusion) ★★☆☆☆

The feeling that a word you just learned is suddenly appearing everywhere.

Right after picking up a new technical term, you start spotting it in your feed, in articles, in meetings. The world did not change, your attention did.

2-4. Architecture and distributed systems staples

CAP Theorem ★★★★★

In a distributed system, you cannot simultaneously and perfectly satisfy consistency, availability, and partition tolerance.

The "pick two out of three" phrasing is the famous one, but in practice it is more useful to think of CAP as describing a design choice that becomes visible when a network partition actually happens: under partition, do you preserve consistency or availability?

Idempotence ★★★★★

A property where performing the same operation multiple times has the same effect as performing it once.

More precisely: applying the operation once or many times results in the same intended effect on the server's state, even if the response payload varies. Networks fail. Retries happen. So a payment request, a webhook handler, or any critical operation needs to be safe to receive more than once without double-charging or duplicating effects. Crucial in payments, job processing, and API design.

Fail-safe ★★★★★

When something fails, fall toward the safer outcome.

Authorization errors fall toward "deny", not "allow". An ambiguous payment state falls toward "hold", not "double-charge". A control system falls toward "stop", not "uncontrolled motion". Foundational in security and safety design.

Foolproof ★★★★★

Design so that human error is unlikely to cause damage. The Japanese-coined equivalent is poka-yoke from manufacturing.

Add a confirmation step to delete buttons. Require typing the environment name to run destructive commands in production. Disable dangerous CLI flags by default. Make inputs into select boxes instead of free text. Leverage the system's design, not the user's vigilance, to prevent mistakes.

Eventual Consistency ★★★★☆

Replicas do not agree immediately, but they will agree given enough time.

Common in NoSQL stores, caches, event-driven systems, and async pipelines. A read immediately after a write may see the old value; given some time, all replicas converge.

Fail-fast ★★★★☆

If something is wrong, stop early rather than carrying the problem forward.

Missing config, malformed input, a dependency that is unreachable: better to fail right at the boundary than to propagate the problem into later stages of the system. Shows up in input validation, config checks, CI, and startup self-checks.

Backpressure ★★★☆☆

When a consumer cannot keep up, slow the producer down.

You see this with queues, streams, rate-limited APIs, and log pipelines. If the consumer is stuck and the producer keeps pushing, memory grows, latency grows, and eventually something crashes. Backpressure is the discipline of flow control.

Graceful Degradation ★★★☆☆

When part of the system breaks, keep as much of the rest working as possible.

If an external API goes down, keep the core flows alive. If recommendations are unavailable, still render the product list. If image processing is slow, still show the text. This is the language of degraded modes and resilience.

2-5. Organization and development strategy

Bus Factor ★★★★☆

A peculiarly engineering metric: the number of people who would need to disappear for the project to be in trouble.

A bus factor of 1 means a single resignation, transfer, or extended absence can break the project. The term is shorthand for risk from siloed knowledge, weak documentation, and weak review coverage. You raise the bus factor with code review, pair work, runbooks, and rotation.

Inverse Conway Maneuver ★★★☆☆

Use Conway's Law in reverse: shape the organization to fit the architecture you want.

"We want these service boundaries, so let's organize teams along those same boundaries." Sits naturally next to ideas like Team Topologies, platform teams, stream-aligned teams, and bounded contexts.

3. How to use these terms

The vocabulary above is useful, but it is not magic.

3-1. Do not let the name end the discussion

"That's just Brooks's Law." "That's YAGNI." "That's Conway." If the conversation ends there, you are casting spells instead of thinking.

The trick is to follow up with something concrete.

[Bad]
"That's YAGNI."

[Good]
"Do we have a concrete requirement for that extension point this quarter?"

[Bad]
"Brooks's Law, so no."

[Good]
"If we add people now, the onboarding and review overhead will probably cost us at least two weeks before it pays back."

Names are shortcuts. Use them to start a deeper conversation, not to skip one.

3-2. Translate the classics into your context

Books like The Pragmatic Programmer, The Mythical Man-Month, The Unix Philosophy, and the rest of the classic software engineering canon still hold up. Plenty of what they describe is directly useful today.

But pulling those terms straight into modern web development, cloud, AI agents, or distributed systems sometimes needs translation.

Stone Soup, today: ship a small, concrete improvement PR and let it pull others in.
Boiling frog, today: ignore the slow drift of CI getting slower and type safety getting looser.
Reinventing the wheel, today: building it yourself without checking the existing libraries. Still valuable as a learning exercise; harmful as a default reflex.
Leaky abstractions, today: even with cloud and AI tooling, you cannot fully forget the layer below.

The point of the classics is not to memorize them. It is to give the awkward feelings you already have in real projects a name you can point at.

And please, do not become the person who weaponizes English jargon to win arguments.

Wrap-up

Thanks for reading this far.

The famous engineering laws and metaphors are not just trivia. They give short names to why estimates miss, why org structure shows up in the code, why public APIs ossify in odd places, why metrics go bad, and why technical debt grows quietly. Once you have the name, you can recall the whole pattern in a second.

If there is one thing I would like you to take away from this article, it is that once you know the name of a thing, you start spotting it in the wild. That is the Joshua Tree Principle in action.

See you in the next one.

About this article

This article is the English adaptation of a Japanese post I originally wrote on Qiita, a developer community popular in Japan.

【エンジニアの教養】なぜかエンジニア界隈で有名な◯◯の法則的なやつをまとめてみた #Security - Qiita

前置きこんばんは、mirukyです。この間のGW中に、高校時代の先輩（テックリード）と飲みに行きました。そのとき先輩が経験した炎上プロジェクトの話になり、先輩が「ブルックスの法則ってあるじゃん。まさしくあれになってさ」みたいなことを言っていたのですが、本で見たこと...

DEV Community: miruky

A Field Guide to AWS CI/CD: CodeBuild, CodeDeploy, and CodePipeline End to End

Introduction

Scope

Table of Contents

1. CI/CD fundamentals

1-1. CI

1-2. CD

1-3. End-to-end CI/CD flow

2. The AWS Code family at a glance

2-1. The four core services

2-2. CI/CD steps mapped to AWS services

2-3. Choosing services in 2026

2-4. Alternatives outside the Code family

3. Source control and where CodeCommit stands now

3-1. CodeCommit overview

3-2. CodeCommit timeline

3-3. CodeCommit vs GitHub, GitLab, Bitbucket

3-4. Migrating off CodeCommit

4. GitHub and CodeConnections setup

4-1. Git and SSH key setup

4-2. Creating the GitHub repository

4-3. What CodeConnections does

4-4. Creating and verifying the connection

5. CodeBuild fundamentals

5-1. What CodeBuild is

5-2. Compute types

5-3. Pricing at a glance

5-4. Your first CodeBuild project

5-5. First build and log check

6. buildspec.yml in practice

6-1. Base structure

6-2. Environment variables and secrets

6-3. Built-in environment variables

6-4. Cache

6-5. Building Docker images and pushing to ECR

6-6. Batch builds and reports

6-7. Webhook-driven builds

7. CodeDeploy fundamentals

7-1. What CodeDeploy is

7-2. Key components

7-3. appspec.yml for EC2

7-4. Lifecycle events

8. Deploying to EC2

8-1. Preparing the EC2 side

8-2. CodeDeploy Agent

8-3. Deployment file layout

8-4. Deployment groups

8-5. Running the deployment

9. Deployment strategies and rollback

9-1. In-Place vs Blue/Green

9-2. Load balancer integration

9-3. EC2 deployment configurations

9-4. Automatic rollback

10. Canary deployments to ECS and Lambda

10-1. ECS Blue/Green

10-2. ECS deployment configurations

10-3. Lambda deployments

10-4. ECS and Lambda hooks

11. CodePipeline fundamentals

11-1. What CodePipeline is

11-2. Source, build, and deploy providers

11-3. V1 vs V2

11-4. Pricing notes

12. CodePipeline V2 in practice

12-1. Trigger filters

12-2. Pipeline variables

12-3. Manual approval

12-4. Notifications and EventBridge

12-5. JSON definitions and IaC management

12-6. From staging to production

13. Advanced pipeline design

13-1. Multi-stage layouts

13-2. Parallel actions

13-3. Multiple sources and artifacts

13-4. CloudFormation integration

13-5. Cross-account deployment

13-6. Cross-region and Lambda Invoke

14. Building a CI/CD pipeline from scratch

14-1. The setup

6. `buildspec.yml` in practice

7-3. `appspec.yml` for EC2

14-4. `buildspec.yml`

14-5. `appspec.yml`