How to put GitHub Actions to work for your software team
GitHub created a surge of interest throughout the developer community when it announced GitHub Actions at GitHub Universe 2018. Actions, still in beta at the time of this writing, will help developers trigger event-based workflows.
Based on GitHub webhooks, Actions-based workflows could be a huge boon to increase automation and aid continuous delivery efforts.
Here's how to use them, and some sample code to try. And here's what this event-driven trend represents, not only within GitHub, but throughout the modern software development ecosystem as a whole.
Meet GitHub Actions
Actions help you create events that are triggered by things in your development workflow—essentially by any GitHub webhook event. With Actions, things such as merging a pull request, pushing a commit, or creating a new issue can act as events, signaling other processes to occur.
With Actions in place, you can initiate functions such as seamlessly building and deploying Docker containers. When you combine Actions into workflows, events can trigger a complex series of processes to run in parallel sequence, enabling more responsive architectures. GitHub states that the goal of Actions is to "automate your workflow from idea to production."
Specific features
Understanding both Actions and workflows is critical to comprehending the scope of GitHub's announcement.
Actions
Actions are Docker containers stored in your GitHub repository, or in other public repositories. Language-agnostic, Actions can be written in any programming language and can interact with the GitHub API. Configured by code, Actions embrace the Git flow and are executed on demand as auto-scaled containers with generous resource limits.
Workflows
Workflows, on the other hand, can be any series of GitHub Actions, triggered by events in your GitHub Webhook repositories. Made of one or more Actions, workflows can be customized for unique development and cloud deployment environments.
Show me the code
If you browse the documentation for Actions, you'll see varying repositories that string Actions together into complex workflows. Note the Action dependencies and other stipulations in this Docker deployment command:
action "Deploy to Production" {
needs = "Provision Database"
uses = "actions/aws/ec2"
runs = "aws deploy --prod"
}
For other examples, let's browse the community-supported library of Actions. Say you wanted to programmatically interact with the npm repository; the GitHub npm Action can be configured within a workflow to test packages and publish to a registry.
workflow "Build, Test, and Publish" {
on = "push"
resolves = ["Publish"]
}
action "Build" {
uses = "actions/npm@master"
args = "install"
}
action "Test" {
needs = "Build"
uses = "actions/npm@master"
args = "test"
}
action "Publish" {
needs = "Test"
uses = "actions/npm@master"
args = "publish --access public"
secrets = ["NPM_AUTH_TOKEN"]
}
Another example workflow is made for AWS; using it, you can build and deploy a container running on Kubernetes via Amazon's Elastic Container Service for Kubernetes (EKS):
workflow "Build and Deploy" {
on = "push"
resolves = ["List Public IP"]
}
# Build
action "Build Docker image" {
uses = "actions/docker/cli@master"
args = ["build", "-t", "aws-example", "."]
}
# Deploy Filter
action "Deploy branch filter" {
needs = ["Push image to ECR"]
uses = "actions/bin/filter@master"
args = "branch master"
}
....
Triggering on every push to that repository, the above workflow will build the Docker image, tag and push the image to the Amazon Web Service EK directory, and create a deployment on the EKS cluster for pushes to the master branch.
There are already many Action flows developed for other cloud container and orchestration tools, including Docker, Google Cloud, Azure Kubernetes Service, and Heroku, to name a few. There is also a dedicated bin of utilities to help build Actions. For those seeking a true maze of interconnectedness, there is even an Action to build further Actions.
Benefits of GitHub Actions
With advanced, complex workflows reduced to simple commands, Action-based workflows can offer impressive benefits to ops developers. You can use GitHub Actions to automate repetitive actions and decrease time spent configuring workflows, giving you more free time to focus on your own domain logic.
Instead of maintaining a sea external DevOps apps and accounts, GitHub Actions is automating software delivery using Git. Teams can embrace a collection of UNIX-like microservices to perform niche tasks, all called in sequence with their custom, event-driven pipeline. Since Actions are defined in your repository or public repositories, executions are handled by a kind of mesh of GitHub repos.
"GitHub Actions are really easy to set up," said Adam Zolyak, developer advocate at Waffle.io
And Actions or workflows are not limited to text editors. GitHub will be releasing a visual editor to create and manage workflows too, meaning increased usability for ops teammates who have less of a coding background.
All in on GitHub as the event-driven platform?
So, what does this mean for the developer ecosystem? Why has GitHub released Actions, or—more interestingly—what trend do GitHub Actions represent in today's software ecosystem?
Our industry is in a moment where event-driven architecture is truly gaining momentum. The use of webhooks to trigger tasks is part of a larger movement. Take Zapier, for example; it connects consumer-facing apps by interlinking actions based on events.
At the same time, one reviewer describes GitHub's move as indicative of an "all processes contained in one" approach that has been gathering steam.
GitHub Actions can be seen as a platform move for GitHub, enabling a new breed of GitHub Apps running on Actions to emerge. Such GitHub Apps have already been included in the beta, including Waffle, which uses Actions to automatically update your GitHub profile status, and Pulumi, which helps deploy Actions to any cloud infrastructure.
The idea of GitHub platform apps is nothing new—GitHub already encourages platform apps for its marketplace and even maintains the Probot framework to help developers create apps through GitHub Services (now slated for deprecation.) Actions is part of its move away from GitHub Services, toward webhooks and interconnected repos.
Trigger warning: Events may trigger actions
Running actions against things in a GitHub repository isn't a new concept. For years, tools like Travis CI, Jenkins, and Circle CI have been automating things based on CI jobs. However, this sort of automation required setting up external accounts, running data through external servers, and potentially buying into a vendor up-sell.
Synchronizing operational events within the GitHub universe, Actions could disrupt (or at least alter) some external cloud offerings. This is especially true of tooling that affects internal DevOps processes that have emerged to ease containerization, such as orchestration, configuration, and deployment.
Of course, for Actions to truly affect the DevOps space, all of your developers must be on board with GitHub, putting even greater faith in the platform to retain open-source roots and ease of use. Since the majority of developers already use Git, this seems doable.
Future evolution
There's a lot to be said for GitHub Actions. Little monitoring, patching, or maintenance is required. And no hosting is required, since it's all in GitHub. Furthermore, because Actions live in containers, they can be written in a language-agnostic fashion. Intrinsically built into GitHub, Action workflows could also negate the need to build external apps to orchestrate particular flows, decreasing technical debt.
Some unanswered questions include rate limiting and scalability of the service, which will likely be addressed alongside the full release. If you haven't signed up for the beta, you can do so here.
Software delivery teams should await the public release of GitHub Actions (no date yet given) with a careful eye to see how it may catalyze their continuous delivery with innovative event-based workflows.