Manual Approvals and Gated Deploys — CI/CD with GitHub Actions

Not every action in a deployment pipeline should happen automatically. Production deployments during business hours, database migrations that require coordination with the DBA team, rollbacks that need incident commander sign-off, and scheduled maintenance window deployments all benefit from human judgment as an explicit gate. GitHub Actions provides two mechanisms for human-in-the-loop workflows: environment approval gates (covered in the previous lesson) and the `workflow_dispatch` trigger with manual inputs. Together these mechanisms enable pipelines that are automated where automation is safe and appropriate, and gated where human judgment adds genuine value. The key design principle is that gates should be meaningful — every gate adds friction, and friction that doesn't prevent real errors will be routinely bypassed or rubber-stamped until it provides zero protection.

Analogy🏏Cricket

🏏 Think of it like cricket: A cricket series is structured in three tiers: the series schedule (which matches are played and when), individual match plans (batting order, bowling rotations, fielding strategy), and specific delivery plans (which balls to bowl to which batsman in which over). The series schedule is the workflow — it defines the overall event. Each match is a job — it runs independently but contributes to the series outcome. Each delivery plan is a step — a specific action with a discrete result. Just as a Test captain doesn't redesign the series schedule for every match but does adjust the bowling plan for each innings, GitHub Actions separates what triggers the automation (workflow) from how independent tasks are parallelised (jobs) from the individual commands executed (steps). The insight is that this separation of concerns is what allows large, complex pipelines to remain manageable — just as a well-structured series plan keeps a touring team organised across multiple venues and formats.