Skip to main content
All posts

Cloud & DevOps

A GitHub Actions Pipeline Small Teams Can Maintain

8 min read

Deployment engineering setup with a laptop, network equipment, and flow diagrams

A useful delivery pipeline is intentionally boring: the same checks run every time, secrets stay protected, failures are readable, and the team knows exactly which release is live.

Begin with quality gates

Trigger checks on pull requests and protected branches. Install dependencies from the lockfile, lint, type-check, test, and build in separate named steps. Clear boundaries make failures faster to diagnose.

Pin action versions and the runtime version. Cache dependencies only after the basic workflow is reliable; an opaque cache should not become the first debugging task.

  • Use the lockfile-enforcing install command
  • Cancel superseded runs on the same branch
  • Set minimum workflow permissions
  • Upload useful test or build reports on failure

Protect deployment

Keep production deployment on a protected environment with limited secrets and, where appropriate, a manual approval. Prefer short-lived cloud identity federation over permanent access keys. Never print environment values for debugging.

Build once and promote the tested artifact. Rebuilding during production deployment can introduce a dependency or timing difference from the version reviewers approved.

  • Separate preview and production credentials
  • Name the deployed artifact with the commit SHA
  • Prevent concurrent production deploys
  • Record the live version somewhere visible

Plan rollback and ownership

A green deployment job does not guarantee a working product. Add a small smoke test for the home page and critical public route, then keep the previous artifact available for rollback.

Make failure notifications actionable and route them to the people who own the service. Include the environment, commit, workflow link, and first failed step.

Chat with me