GitHub Actions: The Best Practice Game Changer

“GitHub? That’s a code repository, right?” said a friend, when I mentioned I was in San Francisco. GitHub Universe, the company’s annual conference, is small but perfectly formed — 1,500 delegates fills a hall but doesn’t overwhelm. And yes, developers, engineers and managers are here because they are pulling files from, and pushing to, one of the largest stores of programming code on the planet.
GitHub representatives would likely dispute the “just a code repo” handle, nonetheless. I would imagine they would point at the collaboration mechanisms and team management features on the one hand, and the 30-plus million developers on the other. “It’s an ecosystem,” they might say. I haven’t asked, because the past two days’ announcements may have made the question somewhat moot. Or one announcement in particular: GitHub Actions.
In a nutshell, GitHub Actions allow you to do something based on a triggering event: they can be strung together to create (say) a set of tests when code is committed to the repository, or to deploy to a target environment. The “doing something” bit runs in a container on GitHub’s servers; and a special command (whose name escapes me…wait: RepositoryDispatch) means external events can trigger actions.
That’s kind of it, so what makes GitHub Actions so special? Or, to put it another way, what is causing the sense of unadulterated glee, across both the execs I have spoken to and those presenting from the main stage. “I can feel the hairs on the back of my neck as I talk about this,” I was told, not in some faux ’super-excited’ way but with genuine delight.
The answer lies in several, converging factors. First, as tools mature, they frequently add rules-based capabilities — we saw it with enterprise management software two decades ago, and indeed ERP and CRM before that. Done right, event-driven automation is always a feature to be welcomed, increasing efficiency, productivity, enforcing policy, governance and all.
Second is: what happens when you switch on such a feature for a user base as large, and as savvy, as the GitHub community? Automation is a common element of application lifecycle management tooling, and multiple vendors exist to deliver on this goal. But few if any have the ability to tell millions of open source developers, “let’s see what you got.”
Which brings to a third point: right now, we are in one of those fan-out technology waves. In my report on DevOps, I name-checked 110 vendors; I left out many more. Choosing a best-of-breed set of tools for a pipeline, or indeed, deciding the pipeline, involves a complex, uncertain and fraught set of decisions. And many enterprises will have built their own customisations on top.
As I wrote in the report’s introduction, “In the future, it is likely that a common set of practices and standards will emerge from DevOps; that the market landscape for tools will consolidate and simplify; and that infrastructure platforms will become increasingly automated.” The market desperately needs standardisation and simplification: every day, organisations reinvent and automate practices which, frankly, is not a good use of their time.
For there to be a better way requires a forum — an ecosystem, if you will — within which practices can be created, shared and enhanced. While there may be a thousand ways to deploy a Ruby application, most organisations could probably make do with one or two, based on constraints which will be similar for their industry peers. With a clear day, a following wind and the right level of support, GitHub Actions could provide the platform for this activity.
Will this put other continuous automation and orchestration vendors out of business? Unlikely, as there’s always more to be done (and no organisation is going to switch off existing automations overnight). However it could create a common language for others to adopt, catalysing standardisation still further; it also creates opportunities for broader tooling, for example helping select a workflow based on specific needs, or bringing in plugins for common actions.
It’s also notable that GitHub Actions is only being released as Beta at this point (you can sign up here). Questions remain over how to authorise and authenticate access, what criteria GitHub will set over “acceptable” Action workloads, and indeed, how Actions will work within a GutHub enterprise installation. Cliché it may be, but the capability creates as many questions as it does answers — which is perhaps just as well.
Above all perhaps, the opportunity for GitHub Actions is defined by its lack of definition. Methodologists could set out workflows based on what they thought might be appropriate; but the bigger opportunity is to let the ecosystem decide what is going to be most useful, by creating Actions and seeing which are adopted. And yes, these will go way beyond the traditional dev-to-ops lifecycle.
One thing is for sure: the capability very much changes the raison d’être for their founding organisation. “Just a code repository” they may have been, in the eyes of some; but a collaborative hub for best practice is what the organisation will undoubtedly become, with the adoption of GitHub Actions. No wonder the sense of suppressed glee.