DevOpsintermediate

CI/CD Pipeline with GitHub Actions

A CI pipeline is either a quiet asset or a noisy tax, and the difference is whether you took it seriously the first week or bolted it on after the team grew. This is the pipeline I set up on every new project: tests, lint, type-check, build, preview deploys, and production releases, all running in under five minutes and giving useful feedback when they fail.

45 min7 steps

Steps

Tools

Outcomes

intermediate

Difficulty

Technologies used

GitHub ActionsDockerVercelNode.js

The methodology

The phases, in order

Each phase below is something I actually run in a project. The descriptions are how I think about the work, not abstract definitions.

Phase

Phase 1 of 7

Workflow File Layout

I split the work into focused workflow files: ci.yml for pull requests, deploy.yml for production, and release.yml for tagged builds. Each one starts with concurrency control to cancel superseded runs, which keeps the cost down on busy branches. Reusable steps live in composite actions so I am not copy-pasting setup across files.

Phase

Phase 2 of 7

Testing and Type Check Pipeline

On every pull request I run lint, type-check, unit tests, and a build. They run in parallel where possible, and the type-check has its own job so a single failure is immediately legible in the GitHub UI. Flaky tests get quarantined into a separate job with retry, never just hidden, so they stay visible until fixed.

Phase

Phase 3 of 7

Build Caching and Speed

Caching is where most pipelines bleed time. I cache the package manager store, the Next.js build cache, and any other framework artifacts keyed by lockfile hash. Done right, a typical PR completes in under three minutes. See edge caching for runtime caching too.

Phase

Phase 4 of 7

Preview Deployments

Every PR gets a preview URL on Vercel or the equivalent. A bot comment links to the preview and includes screenshots of any visual diff. This is the single highest-leverage workflow I have ever added to a team: design and product can review every change without cloning the repo. Also see Vercel vs Netlify for picking a host.

Phase

Phase 5 of 7

Production Deployment

Main branch merges trigger a production deploy with required status checks. I gate the deploy behind a smoke-test job that hits the deployed URL with a handful of canary requests. If those fail, the deploy is marked failed and the previous version remains live. No fancy blue-green, just simple and reliable.

Phase

Phase 6 of 7

Environment Secrets and Permissions

Secrets go in GitHub Environments, scoped per environment so a preview run cannot read production keys. I review the actions permissions on the workflow level and pin third-party actions to a SHA, not a tag. This sounds paranoid until a popular action gets compromised, which has happened multiple times.

Phase

Phase 7 of 7

Notifications and Visibility

I wire failed deploys to a Slack or Discord channel, never spam-success-only-failures, and include a one-click link to the run. For releases I auto-generate changelogs from conventional commits, so the team knows what shipped without anyone writing a release note by hand.

Results

What You'll Achieve

Expected outcomes from implementing this playbook

Automated testing and type-check on every pull request

Preview deployments with bot comments for review

Zero-downtime production deployments with smoke tests

Sensible secrets management and pinned actions

Need a CI/CD audit? DevOps service or start a project.

Use this playbook

Want me to run this with you?

The playbook is the public version. The private version is me running it for your team against a real deadline. If you have a project on the line, that is usually the faster path.

Start a project Just ask a question

Related insights

More on this thinking

The studio journal

Essays and notes that pair with the playbooks.

Insights in DevOps

Filter the journal for pieces on this topic.

Related blueprints

Reference architectures

All blueprints

Production-grade reference systems I have shipped.

Labs

Experiments where I prototype the playbooks in public.

Next up

Performance · 60 min

Optimizing Performance with Edge Caching

Sub-100ms global response times are not magic, they are a stacked set of cache decisions made on purpose. This playbook is the layered caching strategy I use to keep dynamic apps feeling instant: static generation where it fits, edge functions where personalization is needed, on-demand revalidation, and the observability to know whether any of it is actually working.

DevOps

Related Playbooks

Other playbooks in this category

intermediate

Production Monitoring & Observability

Observability is not three pillars on a slide, it is the difference between knowing why your system is misbehaving and guessing. This playbook is the monitoring stack I deploy on every production system: error tracking, structured logging, performance metrics, distributed tracing, and the dashboards and alerts that turn raw data into actionable signal without paging everyone at 3 AM.

Building an AI Chatbot with Streaming

Optimizing Performance with Edge Caching