DOP 303: How To Develop a CLI in 2025

Episode 303

Show Notes

#303: In today’s digital realm, command-line interfaces (CLI) are lifelines for developers, embodying the efficiency and power required to manage complex tasks.

The goal in designing a CLI is not to overwhelm users with command intricacies but to allow them to navigate operations seamlessly and intuitively.

In this episode, we speak with Wesley Beary, a founding engineer at Anchor, about their journey of developing a robust CLI for their product.

Frequently Asked Questions

Why does distribution matter so much for a CLI?

Wesley Beary puts it high on the list on DevOps Paradox episode 303, drawing on having shipped a CLI in Ruby where users had to install a language runtime first. Viktor Farcic says installation instructions beginning with a package manager make him stop reading. Beary agrees the trouble compounds: fine for one tool, and a dependency nightmare as soon as two of them want different versions.

How do you test a terminal user interface?

Wesley Beary found almost no examples with test coverage on DevOps Paradox episode 303, including in the framework’s own repositories. The approach that worked was golden files, recording output and comparing future runs against it. Transient elements such as spinners produced race conditions and flaky tests, so his team now writes every frame like a flip book, accepting redundancy in exchange for consistency.

What should a CLI do when you are not signed in?

Wesley Beary argues on DevOps Paradox episode 303 that crashing and telling the user to do it right next time is the convention rather than good design. If the tool knows you are not authenticated and knows how to authenticate you, it should do that and then continue with the command you originally ran. The same applies to a missing argument, where it can offer a selection list instead.

How do you iterate cheaply on an API and its CLI?

Wesley Beary describes a spec-first approach on DevOps Paradox episode 303. Add the operation to the OpenAPI document, run a mock server generated from that spec, and build the CLI against the mock. Changing a few lines of YAML is far cheaper than changing an implementation and its tests. Once the contract is agreed, the CLI and the API can be built in parallel by different people.

Should a CLI do everything the web interface does?

Wesley Beary says no on DevOps Paradox episode 303, describing an internal debate about account signup that ended with sending people to the browser, which handles federated login without inventing a novel flow. His rule is that there should always be a way to do something, but not necessarily the same way, and that a command can point you at the right URL rather than leaving you to hunt.

How do you get better at designing command line tools?

Wesley Beary recommends becoming a connoisseur on DevOps Paradox episode 303. Use other tools, work out what you like and what frustrates you, and form opinions about why. That matters because you rarely get many attempts at an interface, and because intuition alone does not survive a colleague proposing something worse. Having to explain why a pattern tastes bad is what turns preference into an argument.

What is the DevOps Paradox podcast?

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 303 brings in Wesley Beary of Anchor, previously of Heroku, to discuss building a command line tool: distribution, testing terminal interfaces, spec-first API design, and what a CLI should do rather than what CLIs usually do. Every episode page carries the audio, the video, and a full transcript.

Episode Transcript

Read the Full Transcript

Links from the Episode

Topics

Share and Download

Guests

Wesley Beary

Wesley Beary

Wesley is a tech wizard who has been reshaping the developer experience for over 15 years, turning complex API and open source challenges into solutions loved by developers worldwide.

He is currently shaking up the tech world as a Founding Engineer at Anchor, a dev-friendly platform that provides private CAs for internal TLS encryption. It is making HTTPS certificates easy to get on servers, allowing developers to focus on building rather than managing security. Here’s a blog Wesley wrote about how Anchor developed a CLI and the tools that helped.

Wesley’s many career highlights include his maintenance of Ruby’s excon gem (over 485 million downloads) and suite of fog gems for cloud services. He also led the design of the Heroku public API and played a key role in publishing the pioneering HTTP API Design Guide. Wesley’s insights have guided countless developers in building better APIs.

Wesley is more than an open source expert; he’s a community builder, having organized dev meetups and delivered keynote addresses at conferences for Upstream, ArrrrCamp, and Ruby.

Hosts

Darin Pope

Darin Pope

Viktor Farcic

Viktor Farcic

Viktor Farcic is a member of the Google Developer Experts and Docker Captains groups, and published author.

His big passions are DevOps, Containers, Kubernetes, Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD).

He often speaks at community gatherings and conferences.

He has published DevOps Paradox and Test-Driven Java Development.

His random thoughts and tutorials can be found in his blog The DevOps Toolkit.