The birth pipeline — CI/CD
In a healthy society, new humans aren't assembled by hand at midnight. Every change to DNA goes through the same careful process: review, tests, rehearsal, then birth in production. That process is a CI/CD pipeline.
The journey of a DNA change
Developer pushes code
▼
Pull request → review by another human → automated checks (lint, unit tests, CDK assertions, cdk synth)
▼ merge to main
Deploy to dev → integration tests
▼
Deploy to staging → end-to-end tests, smoke tests
▼ (approval for production, if your team requires it)
Deploy to prod → health checks and alarms watched; automatic rollback on failure
Deploying from GitHub without stored keys
Use OpenID Connect (OIDC): GitHub Actions proves its identity to AWS and assumes a deployment role with temporary credentials. No long-lived access keys sit in your repository secrets.
- In each AWS account, create an IAM OIDC identity provider for GitHub and a deploy role that trusts only your repository (and branch).
- Give the role permission to deploy CDK (typically to assume the roles created by
cdk bootstrap). - Use the role in the workflow:
# .github/workflows/deploy.yml
name: grow-the-cafe
on:
push:
branches: [main]
permissions:
id-token: write # needed for OIDC
contents: read
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npm test
- run: npx cdk synth
deploy-dev:
needs: test
runs-on: ubuntu-latest
environment: dev
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::111111111111:role/cafe-github-deploy
aws-region: ap-south-1
- run: npx cdk deploy CafeSukoon-dev --require-approval never
# deploy-staging and deploy-prod follow the same shape, each with its own
# GitHub environment (for approvals) and its own account's deploy role.
GitHub environments let you require a manual approval before the production job runs, and keep each environment's role ARN separate.
Alternative: CDK Pipelines
CDK includes CDK Pipelines, a construct that builds a self-updating AWS CodePipeline from your CDK app, with stages for each environment. It's a good choice when you want the pipeline itself defined — and evolving — as DNA inside AWS.
Safe births in production
| Technique | What it protects against |
|---|---|
cdk diff reviewed in the pull request |
Surprise replacements and deletions |
| Separate accounts per environment | Mistakes leaking into production |
| Gradual rollout (Lambda aliases with traffic shifting, e.g. via CodeDeploy) | A bad version hurting every customer at once |
| Alarms watched after deploy, automatic rollback | Silent breakages |
| Feature flags | Releasing code before turning a feature on |
Each human, its own birthday
As the society grows, give each human its own stack (or own pipeline), so the Chef can be redeployed without touching the Waiter. Independent deployment is one of the main reasons to have microservices at all — don't lose it by deploying everything as one giant release.
A human should only ever be born through the pipeline: reviewed, tested, rehearsed and watched. If you deploy from your laptop to production, your DNA process has a mutation.
Senior Full-Stack Engineer · AI & AWS. I design and build serverless systems on AWS — and love explaining them simply.