---
title: "GitHub Actions | Skills We Assign For | Azendo"
description: "GitHub Actions as a delivery pipeline — speed, secrets and reusable workflows, and the Azendo roles assigned for CI work."
url: "https://azendo.co/skills/github-actions/"
---

[Skills](https://azendo.co/skills/) CI and delivery 

# GitHub Actions.

GitHub Actions runs automated workflows in response to repository events — builds, tests, deployments — defined in YAML alongside the code. Its advantage is proximity: the pipeline lives where the code and the review already are.

## 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](https://azendo.co/services/qa-engineering-and-test-automation/) 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](https://azendo.co/services/cloud-and-devops/), frequently alongside test automation because the pipeline and the suite are one problem.

## Roles we assign GitHub Actions for

* [DevOps Engineer Cloud and DevOps](https://azendo.co/services/cloud-and-devops/devops-engineer/)
* [Test Automation Engineer QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/test-automation-engineer/)

## Service lines it sits in

* [Cloud and DevOps](https://azendo.co/services/cloud-and-devops/)
* [QA and test automation](https://azendo.co/services/qa-engineering-and-test-automation/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in ci and delivery

* [Jenkins — skill we assign for](https://azendo.co/skills/jenkins/)
* [GitLab CI — skill we assign for](https://azendo.co/skills/gitlab-ci/)
* [Fastlane — skill we assign for](https://azendo.co/skills/fastlane/)
* [Codemagic — skill we assign for](https://azendo.co/skills/codemagic/)
* [TestFlight — skill we assign for](https://azendo.co/skills/testflight/)
* [App Store Connect — skill we assign for](https://azendo.co/skills/app-store-connect/)
* [Play Console — skill we assign for](https://azendo.co/skills/play-console/)
* [CodePush — skill we assign for](https://azendo.co/skills/codepush/)

## Tell us what your roadmap needs GitHub Actions for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)