Github Actions is a game changer. I think we are about to see an unprecedented move to Actions as the continuous integration tool of choice. Its convenience and tight integration with GitHub means developers will be jumping into CI for the first time, and adding CI automation in places where previously they might not have bothered to. From a technical standpoint, there is a lot to like about actions. Organizations that are on GitHub cloud or moving there will appeciated the tightly integrated CI tool.
GitHub is by far the most widely used git-based repository service. It’s the de-facto standard for open source, and individuals personal code repos. Many organizations (all of the ones I have been a part of) have moved to GitHub cloud. Having a CI system right next to your repos is a major convenience. Adding a few lines of YAML is enough to harness time-saving automations. CI was once something you would only set up for large projects, perhaps only in a work setting. I think that’s changing, and CI will be table stakes for projects on GitHub. I’ve even started creating CI automations for my smallest personal projects. This site is built and deployed by actions upon push. I hope to see people with no CI experience jumping in soon.
Cloud-Based and Serverless
Organizations are increasingly moving to cloud-based server less solutions for code and collaboration tools such as G-Suite for businesses, JIRA cloud, Figma, Slack and so on. We’ve graduated from self-hosted services, which are a headache to keep operational and up-to-date. Cloud-based tools are a boon for remote work too since they obviate the hassle of VPNing to the corporate network to access crusty legacy applications with no real security. On the spectrum of things one could self-host, a CI tool is about as hairy as it gets. There are plenty of CI options in the cloud, but many have high barriers to entry in the form of fixed monthly pricing or oddly-specific configuration and domain specific languages. None of them feel as easy, polished, or tightly integrated with existing GitHub-centric workflows as Actions does. Actions has the most “serverless” pricing model which bodes well for workloads both large and small.
My CI experience began with bash scripts and git hooks, follwed by Hudson, Bamboo, Jenkins, and most recently Drone. Something Drone really got right was creating the CI flow with a series of steps run inside of containers. This guarantees a level of isolation, repeatability, and portability of the pipeline which just isn’t the standard or natural thing in other CI systems. Actions feels very much like Drone: “Workflows” are defined in YAML, and execute in an ephemeral environment, inside of containers, optionally using “Actions“ (analogous to drone plugins). An action is essentially a containerized command line tool with a convenience wrapper that lets you configure it via the workflow YAML. Because the workflow is executed in a consistent environment, and configured in a standard way, it is possible to run a workflow from an alternate server, or even a local machine with some basic “runner” software. GitHub says this will be available officially, but at time of writing there are just a few open-source runners available.
“Community” is obviously huge with open source, and with GitHub. They’ve done well encouraging collaboration through their tools. Users are able to implement handy Actions in a typical repository and then publish them to the marketplace. I expect to see the actions marketplace flourish up in the same way that Dockerhub has, with handy utilities covering just about every use case in no time.
I’m excited to see where this goes, and I’ve got no doubt it will be big.