If I had a nickel for every time I heard a "command line vs. graphical user interface" argument, I would be a very rich man. But, if I'm being honest, I find these types of disagreements silly. In the end, the tools don't make the developer, do they?
Unfortunately, it's a common flame war in nearly every software development community—The implication being that developers who use graphical user interfaces (GUIs) are inferior to those who use command line interfaces (CLIs). While it may be true that command line tools often have more power, they also come with a steep learning curve that can make it difficult for new developers to learn them. On the flip side, graphical user interfaces for command line tools are very easy to consume, and can even be used by experienced developers to speed their workflow up. Both solutions have their merits, but rather than picking one over the other, it is important to understand where each one excels so you can pick the right tool for any job.
As an example, I often use a graphical version control client like SourceTree to get a high level view of a Git repository I am working with, but when it comes to actually managing that repository, I prefer to use the command line. Using the defining features of two different tools provides the best of both worlds, which in turn makes me a more productive and in-control developer. Because of the pros and cons associated with both low-level command line interfaces, and easy-to-use graphical user interfaces, Wercker has options to address both methods of managing a continuous delivery pipeline.
The Graphical User Interface
Before we get into what can be accomplished with Wercker's CLI, let's first take a look at their GUI. As mentioned above, Wercker's GUI excels at simply getting things done. From the initial application creation to triggering automated builds and deployments, there is very little that can't be accomplished in Wercker's web interface.
Wercker Workflows Editor
The defining feature of Wercker's GUI is the Workflows editor. This page gives you the ability to define automation pipelines, and then chain them together to automatically run complex tasks based on the branch name and a simple git push. While the interface for doing this is relatively simple, the power that it provides is incredible.
Wercker Access Management
It is also important to mention that Wercker’s GUI is also the place where Access Control settings can be configured. While many of the build and deploy features exist in both Wercker’s GUI and CLI, these two features are unique to the web interface alone.
The Command Line Interface
On the flip side, the Wercker CLI is the perfect tool for quickly and easily running your Wercker build process locally. Rather than having to push changes up to your version control system to trigger a Wercker build, the Wercker CLI can be used to run builds in a local container environment. This allows you to use the same configuration in both development and deployment, which provides much better environment parity and ensures consistency every step of the way.
The reason for this flexibility comes from the wercker.yml configuration file. This file, which is required for every project, tells Wercker exactly how to build, test, and deploy an application. The big advantage to handling the configuration this way is that it keeps it with the code, rather than locking it up in Wercker's web interface. This allows all CI/CD settings to be kept in version control, which in turn provides a high level of transparency and reliability when making changes.
Additionally, the Wercker CLI can be used to diagnose issues with failed automated builds. When something goes wrong with a pipeline, the CLI can be used to pull down images of failed builds, which can then be run in Docker and diagnosed.
Given multiple options, there's no right way to use any platform, but that doesn't mean some interfaces aren't better suited to particular workflows than others. While this article only touches lightly on the advantages and disadvantages of Wercker's CLI and GUI tools, the benefits of each one should be readily apparent.
About the Author
Zachary Flower is a freelance web developer, writer, and polymath. He has an eye for simplicity and usability, and strives to build products with both the end user and business goals in mind. From building projects for the NSA to creating features for companies like Name.com and Buffer, Zach has always taken a strong stand against needlessly reinventing the wheel, often advocating for the use of well established third-party and open source services and solutions to improve the efficiency and reliability of a development project.
We’re hiring! Check out the careers page for open positions in Amsterdam, London and San Francisco.
As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using Wercker, be sure to tweet out your #greenbuilds, and we’ll send you some swag!