GitHub Actions

For projects already living in GitHub, GitHub Actions is often the simplest path to CD — no separate system to run or maintain, workflows live next to the code they act on, and it integrates cleanly with everything else GitHub already handles (releases, environments, required reviewers). This site’s own deploy pipeline runs on it, and I’ve migrated real production build pipelines from Jenkins onto it with keyless cloud authentication — not just used it for something this small.

Where it fits

For projects hosted on GitHub without an existing CI/CD platform, Actions covers a lot of ground on its own — build, test, and deploy — without introducing a new tool. Where a heavier system like Jenkins or ArgoCD is already in place for other reasons, Actions still earns a role as the CD layer specifically for GitHub-native workflows: publishing a site, cutting a release, deploying a static artifact.

Principles that hold up

• Environments with required reviewers for anything that deploys somewhere real. A production environment with a manual approval gate turns “push to main” into a two-step, auditable action instead of an implicit deploy.
• Pin third-party actions to a commit SHA, not a floating tag. A tag like v4 can move; a SHA can’t. For anything with write access to secrets or a deploy target, that distinction matters.
• Reusable workflows over copy-pasted YAML. Once the same steps show up in more than one workflow file, a reusable workflow keeps them in one place — the same instinct as a Jenkins shared library.
• Concurrency groups to prevent overlapping deploys. Two pushes to main within a minute of each other shouldn’t race to deploy; a concurrency group with cancel-in-progress (or a queued group, depending on the risk) makes the ordering explicit instead of accidental.

Dependabot

Dependabot is the low-effort half of dependency hygiene: it opens a PR when a dependency has a new version, grouped and scheduled rather than one PR per package per day. A few habits that keep it useful instead of noisy:

• Group updates (by ecosystem, or by a shared prefix) so a week’s worth of patch bumps lands as one reviewable PR instead of a dozen.
• Separate cadence for security updates. Security advisories should open PRs immediately regardless of the regular update schedule — that’s Dependabot’s actual job, and it’s worth confirming it’s configured that way rather than assumed.
• Don’t auto-merge blindly. Auto-merge is fine for patch-level bumps with a passing test suite as the gate; anything major-version deserves a human look at the changelog first.

See Keeping Updated for how this fits into the broader update cadence.