GitHub’s Actions Challenge Traditional CI Vendors

Source- forbes.com

In the week since GitHub announced its new Actions capability, I’ve been speaking with developers and colleagues about the implications.

There is no doubt that Actions was the most significant announcement at this year’s Universe conference, held in San Francisco, CA. It was met with considerable enthusiasm from those present, even taking into account the boosterism from the more committed GitHub employees present.

In essence, Actions provide a mechanism for developers to write event handlers in a language of their choice that will be executed inside a container (one per Action) on systems owned and managed by GitHub. Actions can respond to a variety of events, and can be connected together into pipelines. The feature is similar to Yahoo Pipes, or the Unix file-and-pipe metaphor, with similar flexibility, power, and complexity.

The ability to react to a code push event and perform an action such as performing a new build has some traditional Continuous Integration(CI) vendors nervous. And they are right to be, because GitHub’s ambitions extend well beyond continuous integration and delivery.

“If we chose to, we could have had a build step that kicked off any build provider out there,” said Jason Warner, SVP of Technology, “Cloudbees, TravisCI, CircleCI, any of them.” Or, in fact, Actions could perform the build process itself, negating the need for a separate build tool completely, and this is what has the CI vendors worried.

“CI/CD is just a narrow use-case for Actions,” Warner said.

However, some developers I spoke to saw it more as a catchup move. “Both GitLab and Bitbucket have had something similar for a while,” said one attendee who wished to remain anonymous. “Actions does look more polished, though,” he conceded.

And I believe this is the important, underlying point: reacting to code actions with code is the way the industry is moving. The entire software stack is becoming programmable in the same way that infrastructure became programmable with the advent of cloud and infrastructure-as-a-service. GitHub had to provide something like Actions because this is what developers need to perform their jobs today.

GitHub Actions is still very new; it’s only in a limited private beta at the moment, so most developers can’t try it out yet. I suspect that it will be restricted to some easy to use, basic functionality, and more sophisticated use-cases will be unwieldy, at least in the current iteration.

As Actions matures, we can expect it to be extended to handle more complex situations, and this is the challenge before traditional CI vendors: we can all see this coming, so how to react?

If they’re smart, they’ll capitalize on their own strengths that build on top of GitHub, such as the ability to interoperate with other systems. GitHub Actions is limited to GitHub, obviously, and there are plenty of organizations that use other source control systems, which limits GitHub’s appeal. CI vendors who can provide portability and interoperability, particularly in the heterogeneous environments of most enterprises, will continue to do well.

Actions will undoubtedly be a boon to smaller and less complex projects that can’t justify the overhead of complex build systems, and we can expect all kinds of amazing things to be demonstrated as more developers get access to Actions and let their creativity loose. We saw an early hint of this during the keynote on the second day when Microsoft’s Jessie Frazelle demonstrated her own use of Actions, though she did caution people not to copy her code. “Do not emulate my behaviour,” she said.

I suspect that a lot of people will ignore this advice.