GitHub Workflows

GitHub Actions brought CI/CD configuration into the repository itself, which is where it always should have been. Workflows live in .github/workflows/ as YAML files, are versioned alongside the code, and run on the same triggers you're already thinking about — push, pull request, release, or on a schedule.

The marketplace of reusable actions covers most of what you'd otherwise script from scratch. Checking out code, setting up a Node version, caching node_modules, publishing to a registry — these are all single-line steps rather than shell scripts you maintain yourself. Writing a custom action when you need one is straightforward too: either a Docker container or a JavaScript action, with the same YAML interface as anything from the marketplace.

For a typical front-end project the workflow is simple enough to fit in a single file — lint, type-check, build, and optionally run tests on every PR before anything merges. Pairing this with branch protection rules that require a passing workflow before merge adds a layer of confidence that's hard to replicate with process alone. It's the kind of setup that pays for itself the first time a broken build gets caught before it reaches production.