If You Care About It, Automate It with Atomist

Published in

The Composition

6 min readOct 11, 2017

In previous posts, I’ve written about better project creation and evolution, and Atomist out of the box features like our Slack lifecycle support. Today I’m excited to share Atomist’s bigger vision around Development Automation.

Development Automation

Development Automation means automating development activities that can better be performed by a machine, saving humans for tasks where we add business value.

For example, when an API changes, a responsible developer notices and informs people. A responsible developer runs the tests on downstream projects when changing a library. They keep track of pull requests needing review and issues ready to close. Such important tasks distract from actual development. With automation, we can do them better and smooth our work.

I care deeply about enabling developers to focus on what really matters. This was the driving force behind the Spring Framework. Frameworks solve generic problems so that developers can add value in areas where we offer unique competitive advantage. But frameworks can only shoulder some of the overall burdens of development. Automation is the next frontier.

Atomist’s vision is a new developer experience, where automating our work is so easy that we do it much more, steadily increasing our productivity by automating what stymies us.

CI was a big step on the journey to automation: invaluable, but not sufficient. Many tedious tasks performed by developers can only be automated with greater understanding of what assets and changes mean. Atomist seeks to provide that. The Atomist connected data model makes it possible to comprehend the event stream around your team’s activities. It spans:

The big picture: the development team and everything it works with: repositories, issue trackers, communication channels, deployments…
Code and configuration in individual projects, including the structure of source files, the configuration model, and the semantics of changes.

With such understanding, many steps can be automated that previously could not, at least in a general way. For example:

Creating new projects based on organizational conventions, including creating repositories and the ancillary things around them such as issue trackers and Slack channels.
Reviewing code, and editing code in place, the same way a human would.
Applying these reviews and changes across many repositories: for example, upgrading a dependency across an entire organization.
Noticing important semantic changes in a project, such as the removal of a REST endpoint, and notifying other teams who might be affected.
Testing the impact of the changes in a PR on a library repository across all projects that depend on that library and setting an appropriate status on the PR.
Reacting to a failed deployment to ensure the right people are notified. For example: the node that just went down in deployment had most recently been updated by Adele’s commit. She should be notified via Slack direct message.

There are three main types of action a developer might take that Atomist helps to automate:

Notification. Who should know about this event? Notifications often need to be actionable, and it’s critical that they are correctly routed and filtered. Both routing and filtering require understanding of both the event and its context, lest notification streams become firehoses of spam that everyone ignores.
Making a code or configuration change. With the rise of configuration as code, more and more things are driven by source code versioning.
Performing another action that affects the state of the world, like raising an issue. A developer might do this via a command line, a shell script or a UI; Atomist can do so via API calls or invoking shell scripts.

Automating such actions can not only save developers time but reduce errors, improve repeatability and increase visibility. Something once siloed on a single developer’s machine or contained in a shell script manually copied from repository to repository can became available to the whole team and made consistent across all projects, ensuring everyone uses, and is able to improve, the best available solution.

How Atomist Works

Atomist has the following core features:

GraphQL API exposing a model of your environment, tracking connections between relevant events like pushes, builds, and deploys and linking back to humans and to tools that track our work (issues).
Subscriptions to events, with access to this model.
A powerful client side programming model for working with our server and understanding and updating the contents of projects, including drilling into the structure of code and configuration. Think of the latter as an API for code.
Secret management enabling API calls and other actions to be made with knowledge of the current user role.
A powerful Slack bot that makes it easy to implement custom commands, update messages and send actionable messages. For example, when a build starts, send the project team a build started message; if it fails, update that message to show the status and add a restart button.

Your automations live in projects that are clients of the Atomist API and can run anywhere you like, communicating securely with the Atomist server. In time there will be multiple client libraries, but the first is our open source node.js client, written in TypeScript.

We chose GraphQL as our primary API protocol, because it’s well suited to exposing rich data models and is supported on many platforms. It also offers excellent tool support. You can explore the API to build queries to use in your automations. For example, this query against the Atomist API enables us to look at the data surrounding Builds, linking the last committer to their Slack id:

Let’s see the code! To show the range of possibilities in custom automations, let’s consider two examples: Reacting to an event in your development stream and inspecting code across many projects.

Reacting to issue creation

Let’s consider an event handler that reacts to the creation of new issues within a repo by sending a message to the associated Slack channel.

We begin by exploring the data model in GraphiQL to arrive at the correct GraphQL query, then create a TypeScript event handler to subscribe to matches:

The implementation of the handle function returns a promise. Although we included all code in a single file for clarity in this case, if we externalize the GraphQL we can generate types to make our handler typesafe.

Inspecting and modifying code

Especially in a world of microservices, when new projects are created constantly, it can be hard to keep things in synch. Often we don’t even know what we have in our organization.

Consider an organization that has many Spring Boot microservices. Over time, things may have drifted. How many of them are on the current version of Spring Boot? An Atomist automation can find the answer.

Here’s the result of invoking a command handler in Slack, across an organization with hundreds of repos:

This is a command handler, which is invoked by a user action, such as typing its name in Slack. It can take parameters, like desiredBootVersion in this example, specifying valid input.

A project reviewer like this is a special type of command handler that extracts information from repositories. The ReviewerCommandSupport superclass used in this case runs the same reviewer function across all repos in the current team. You don’t need to worry about how repos get cloned, or (in cases where you issue updates) the details of creating branches and pull requests. The code is easily testable using the InMemoryProject implementation of the Project interface.

We use a microgrammar to parse the Maven POM of each project. It’s easy to work with the Project interface to view or manipulate project content, using microgrammars or otherwise.

The code is here, and reference documentation is here. A project editor can update project contents across many projects, making pull requests. The corresponding Spring Boot version editor is here.

Next Steps

Atomist is ready for you to try today.

Enable the Atomist out-of-the-box features for greater visibility into your project lifecycle and convenient GitHub commands in Slack. (Go to https://atomist.com and click Get Started.) Their implementation is open source and a useful guide.
Start writing your own automations today by cloning our starter project and referring to our samples.
Get involved in our open source projects, including the node client and microgrammar library.

As developers, our attention is precious. We can preserve our attention in daily activities and focus on real business decisions, when we automate away incidental, distracting details of our work. Atomist is here to enable that, and empower every development team with the ability to create their own custom automations.

We’re excited to see where Atomist can take you today, and where you want to help take Atomist tomorrow!