GitHub Actions.

Where GitHub Actions fits on a long engagement.

Keeping the pipeline in the repository means a change to the build is reviewed like any other change. That single property removes a whole category of problem where CI configuration lives somewhere else, is edited by one person, and nobody can say when it last changed or why.

Pipeline duration is the thing worth defending. A suite that takes twenty minutes changes behaviour: people batch commits, stop running it locally, and merge on hope. Caching, parallelism and moving slow checks off the critical path are worth real effort, because the cost is paid on every commit by every engineer.

What an assigned team does with GitHub Actions.

Pipeline duration is a tax paid by every engineer on every commit, and it rises invisibly. Nobody notices the week it goes from six minutes to nine; everybody notices eighteen months later when people have stopped running it locally and started merging on hope.

Keeping it fast is continuous maintenance rather than a one-off fix, and it is usually assigned alongside the test suite it runs, under QA outsourcing where the suite itself is the slow part.

What we use GitHub Actions for.

• Cutting a slow pipeline Caching and parallelism applied so the feedback loop is short enough that people actually wait for it.
• One workflow across many repositories Reusable workflows replacing copies that have quietly diverged.
• Deployment with a gate Environments and approvals configured so production requires a decision rather than a merge.

How GitHub Actions capacity is assigned.

Pipeline work is assigned under DevOps as a service, frequently alongside test automation because the pipeline and the suite are one problem.