Just Let Us Code It: Putting Developers at the Center of Software Delivery

At this year’s GitHub Universe — the first after Microsoft announced its intention to acquire GitHub — the message is that the future of software will have “developers at the center.” At Atomist, we couldn’t agree more.

We’re excited to see GitHub embrace two of the key tenets of Atomist: that it’s time to think of software delivery in terms of events rather than pipelines; and that you should be able to code your delivery pipeline, as well as your applications.

We’re not surprised to see GitHub moving forward as a good citizen. It’s good to see technical progress, and we see rich integration potential between GitHub and Atomist.

GitHub Actions

The most interesting announcement is GitHub Actions: a way of specifying custom logic around software delivery inside GitHub repositories.

GitHub Actions are currently in private beta, so it’s possible technical details will change.

One way of looking at this is GitHub offering to host the compute to handle GitHub web hooks, as the events exposed correspond to existing GitHub event hooks. You could do all of this without GitHub Actions: it becomes more convenient and hopefully cheaper.

But the implications are bigger, elevating events to the building blocks of software delivery. Traditional delivery solutions use pipelines rather than events to compose delivery; GitHub embracing events is a big deal.

Even more important, GitHub Actions make scriptability a core concept, something called out in the announcement:

We’re bringing the same tools you use while writing software to the rest of your development workflow, allowing you to focus on what matters most: code.

This is exactly the motivation behind Atomist. And we believe we’ve taken it to another level.

The future of software delivery is about events and programmability, not traditional pipelines. And it’s about code, not YAML.

GitHub Actions and Atomist

GitHub Actions are a step in the right direction. However, this journey goes beyond single source code hosting platform — even the most popular — and must encompass a true API.

In my last post, I talked about three key Atomist concepts. Let’s see how GitHub Actions relate:

• Replacing the model of one repo per pipeline with an event hub. GitHub Actions reflect the recognition that event handlers are more flexible than traditional pipelines, and are the right way to build delivery flows. GitHub Actions are presently limited to per-repo scope (encountering the same duplication problem encountered with traditional pipelines), but given the flexibility of an event model, we presume that this limitation is likely to be lifted.
• A rich correlated model for our projects and what’s around them. GitHub already provides this for its own data via its GraphQL API. However, it doesn’t extend beyond data that GitHub itself holds, which usually doesn’t extend throughout the delivery process, even for GitHub repos.
• Specifying behavior in a full-featured programming model, with a beautiful API. The GitHub Action model rests on shell scripts, which can optionally be packaged in Docker containers. There is a contract for environment variables and exposing checked out code, but it’s necessarily clunky. This low level approach makes sense given GitHub’s objectives of inspiring an ecosystem, but it’s not ideal for end users.

The Atomist and GitHub Action approaches are complementary: GitHub Actions are a lower level substrate we can take advantage of to run an Atomist Software Delivery Machine.

Putting the two together will enable developers to take advantage of the GitHub-hosted compute, while gaining significant benefits. For example:

• Eliminating workflow duplication. Atomist can add GitHub workflow files to all your repos, avoiding the need for a workflow per repo. Delivery flows are naturally a per-team level concept rather than a per-repo concept — Atomist enables you to express them as such. And you don’t need to sacrifice power to avoid duplication: Atomist push rules make it possible to apply consistent handling across logical groups of repos.
• A rich API. We agree that you should bring “same tools you use while writing software to the rest of your development workflow.” The logical consequence of this is to go beyond Bash. You don’t write software in Bash: You use modern languages and frameworks. Atomist gives you a beautiful programming model in TypeScript, a fantastic modern language. The programming model extends to working with your source code, enabling you to automate many tasks.
• Portability across deployment environments and source code hosts. Run your Software Delivery Machine where you like. For example, running via GitHub actions may make sense for GitHub.com users, whereas our enterprise customers generally prefer to manage their SDM instance — for example, to allow them to reference in-house resources. Use a consistent delivery approach across all your repos, regardless of whether they’re on GitHub, BitBucket or GitLab.

Atomist provides the API for software, enabling you to write code that works against your code and the delivery process around it. The same powerful, open source API runs everywhere. It runs locally, purely against git. And it runs against web hooks from GitHub, BitBucket, GitLab, Jenkins and other tools.

We see GitHub Actions as another substrate on which an Atomist SDM can run. One programming model, multiple bindings, enabling users to run their automations where it most makes sense. One portable solution; multiple best-of-breed tools.

As the GitHub Action model progresses through private beta, we look forward to making this integration available.