Workflow automation — CI/CD, testing gates, and deployment pipelines as code
CI/CD is now table stakes for every engineering team. GitHub Actions is the most widely used CI platform for teams already on GitHub. Even if you're not the one writing workflows, you need to read, debug, and extend them — and understand why a workflow failed before you can unblock your own PR.
CI pipelines are central to the "how do you ship code" discussion. Sketching a basic workflow and explaining triggers, jobs, and steps signals production engineering maturity.
A workflow is a YAML file in .github/workflows/. It defines triggers (when to run), jobs (what to run — each on its own fresh VM runner), and steps within each job (sequential commands or reusable actions). Jobs run in parallel by default; use needs to chain them.
Think of each job as a fresh VM: spun up, steps run in order, then torn down. No state persists between jobs unless you explicitly share artifacts or cache.
The test and lint jobs run in parallel, each on a fresh runner. A failed step stops that job — the workflow is marked failed, blocking PR merge when required status checks are enabled.
Never hard-code secrets in workflow YAML — always use the secrets context. Matrix builds are the idiomatic way to test across multiple versions without duplicating job definitions.