One Great Delivery Experience, Your Favorite Tools

Responses to my recent talk at Spring One Platform were enthusiastic, but included comments along the lines of “Wow, now I understand.” For those who don’t have time to watch that talk (although I hope you do!) I’d like to address the key questions. What is Atomist and why is it important? How does it relate to technologies you may already be using?

Atomist Core Concepts

Atomist is a CD and automation platform designed for the cloud native era. It enables you to achieve your ideal delivery experience across all your projects, shaping and evolving it via a beautiful API.

Atomist is a response to urgent problems. First, traditional CD approaches aren’t designed to cope with hundreds or thousands of services, and lead into a dead end of duplication and wasted effort when pushed beyond their limits. Who wants to update YAML build pipelines across all your repositories? Second, we’ve barely scratched the surface in automating our daily work, which hampers our productivity and causes errors. Automating delivery is crucial, but just a start: we do far too many things by hand, such as creating projects, updating dependencies, raising tickets for provisioning and notifying teammates of things they might care about.

The Atomist solution starts with three big ideas:

1. Rethink the traditional model of one delivery pipeline per repo, replacing it with an event hub. Instead of having many distinct pipelines with lots of duplication, we respond to pushes using team-wide policy. One pipeline per repo is the wrong granularity: Delivery requirements are typically at team level.
2. Provide a rich, correlated model for our projects and activity around them, such as pushes, commits, PRs, builds, issues and deployments. To get a great end-to-end experience, we need to see and understand what each event means in context.
3. Specify behavior in code in a full-featured programming language, rather than an unholy mess of YAML and Bash or an explosion of checkboxes. Once we have an API for software we can benefit from seven decades of practical computer science, and achieve our ideal delivery process, while automating many other things. We can benefit from the same level of testability, modularity and tooling that we take for granted in developing our applications themselves.

In our work on Atomist, we’ve learnt that:

• It’s vital to bring the people into the process. This is why Atomist emphasizes ChatOps, enabling actions as well as notifications. This enables us to speed the work of humans by notifying them of things they care about, and asking them to make decisions that should not be automatic.
• Full control over delivery requires the ability to understand and manipulate code. This seems obvious, but it’s not something that CI tools have emphasized, instead using clumsy mechanisms like commit markers. Only when we understand the content of a repo, and the semantics of each change, can we perform truly sophisticated delivery. For example, we can work out if we should build and deploy in response to a given push.

This novel approach enables a great developer experience. It allows team-wide policies that can can apply to all projects, or any group of projects. It enables teams to capture and share knowledge through automating important tasks. It elevates delivery and automation from tactical to strategic: from one-off, per-project hacks, to an engineered, team-wide solution.

Playing Nice With Others

What if you are already using Jenkins or another CI tool? Do you need to throw out your investment to adopt Atomist? Absolutely not.

Atomist provides you with a great team-wide end-to-end delivery experience regardless of which tools you use. Atomist provides a consistent over-arching experience, enables consistent policies to be applied across many projects, and enables dramatically superior scriptability to add rich functionality.

Suppose you use Jenkins. You can retain your Jenkins pipelines and have Atomist help by generating pipelines and keeping them up to date. Atomist adds value by automating many code-related concerns (like dependency updates and correcting common errors) and providing the ability to apply behaviors consistently across many projects. (For example, adding a security check across all your projects, with a single change.) You get to use Jenkins for what it’s good at, no longer suffering from what it’s not. Ideally, you’ll kick Jenkins builds off from Atomist, enabling Atomist “push rules” to determine whether or not to build a push.

Atomist can also help get the most from static analysis tools like SonarQube or security scanning tools like Snyk, ensuring that they run on all projects, all the time. Experience shows that while such tools are capable, rollout is a challenge.

Choice is core to Atomist’s approach. GitLab aspires to be “the only single product for the entire DevOps lifecycle.” We agree on the problem but disagree on the solution. The industry desperately needs a single experience for the entire lifecycle, but this should not mean a single product. It’s vital to be able to choose best of breed tools. No vendor will ever provide a great solution for everything; products get better and worse over time. By focusing on the overall experience, Atomist can provide a great solution that enables individual tools to be added or switched out over time. (Of course, Atomist supports GitLab.) By focusing on the overall experience, we can innovate there rather than waste effort reinventing good piece parts.

Choice matters in deployment. Kubernetes is exciting, but it isn’t the ultimate choice for everything, and we’re skeptical about the trend toward tying things to it. (For example, when developing Spring Boot applications locally, I prefer CD to deploy with Maven on my local machine, rather than to Minikube or another Kubernetes cluster. Atomist gives me the same experience, but it’s dramatically faster and has a much smaller footprint.)

If you’re a Spring developer, emphasis on a great overall experience while maximizing choice within it will seem familiar. For example, Spring never provided its own transaction manager, instead defining a consistent model for delimiting transactions and enabling people to choose for their environment.

Learn More

For a longer introduction to Atomist, see The Future of Software Delivery is Code. My talk at Spring One Platform covers similar ground, but with a demo:

You can download the Atomist CLI and get started on your local machine in a few minutes. Try it and you’ll see how Atomist can help you in many of your daily activities, from creating new projects through ensuring consistent delivery at scale and spotting and even correcting common errors. Above all, it gives you a beautiful API that can be used to take your development and delivery experience to a new level.