Here at Phase2 we are always hard at work to provide the best experience for our clients and our teams, thus the evolution of our toolkit is never done. Outrigger is our open sourced Docker-based development environment.
We use it to train our staff on containers, ensure consistency across environments and between our clients and internal teams during development, and as a rocket launcher to get our projects off the ground and into orbit in no time with devops best practices for environments and configuration.
This release of the Outrigger CLI, rig, got a big version bump for a few reasons we’d like to touch upon.
While most of us locally develop on the macOS platform and we’ve long deployed to Linux, we are seeing Linux appear more and more for local development in the open source space, at our clients, and in our partner organizations.
While most of the motivation for making Outrigger in the first place was to make what is easy on Linux just as easy on the Mac, we realized that for folks doing development on Linux things were now harder. The Outrigger CLI was not helpful, difficult to get setup, and typical project configurations actually caused confusion. This led to an inconsistent experience when our teams had mixed platform development happening.
With this release, the Outrigger CLI now has full Linux compatibility across all commands (steps not needed on Linux are skipped). We also now include .deb and .rpm packages in our releases to make it simple to get `rig` installed and ready to roll. Our generated project configurations also improve cross platform compatibility so you no longer need to know when to switch to an alternate form of a docker-compose command.
One of the best features of Outrigger is the bundled DNS subsystem that allows local dev environments to realistically emulate higher level environments with services running on different machines. The Outrigger DNS system is now configured automatically for Linux users so commands like `rig start` really do get Linux users up and running with no extra system configuration or startup scripts required.
We’ve added a few new features to improve the developer experience. Longer running Outrigger CLI commands now include Desktop Notifications to let you know when they have completed. Don’t worry, if you are not the notification type they can be easily disabled with a simple command line option or environment variable (see `rig help` for details).
The 1.3 line of the Outrigger CLI introduced the concept of project based configuration files that allow you to create collections of project shortcuts to share amongst the team through the `outrigger.yml` file. This release will now recursively look up through project directory structure for the `outrigger.yml` file which allows you easy access to automation scripts no matter where in your project hierarchy you may be working.
The Unison volume syncing we added in the 1.3 release was limited to synchronizing the directory where the `rig project sync:start`command was run. We now have a variety of ways to discover the sync directory including a `--dir` argument that allows you to provide the location explicitly.
We have expanded our verbose logging to include all commands and arguments that are called on externally executed CLI tools. This helps provide insight into more of the steps rig is taking to manage configuration and Docker resources on the developer's behalf.
Additionally, `rig project run` scripts will now display the collection of all commands configured for that script in the associated help guidance seen via `rig project help run:<script>`. This is another way we are aiming to increase the visibility of what our tooling is automating for those that have the desire to dig deeper and expand their knowledge.
The last of our new features was a total overhaul of how the Outrigger CLI reports errors and handles return codes. There is now a consistent format for error messages and a small collection of error codes that make it easier to determine why something may have gone wrong as well as help support more automation of the Outrigger CLI itself.
As part of the evolution of the Outrigger CLI, we sometimes need to part ways with things that are no longer needed or features that may be confusing as we find better ways to approach. As of 2.0.0 we have removed the `rig watch` command that was deprecated as of v1.3.0. The watch command was no longer needed once the introduction of the Unison file sync system was put in place.
We have also removed the CLI argument for the `rig project sync` volume name. This name can now be specified in the project configuration file or determined automatically based on the folder location.
Paying down technical debt
No release would be complete without doing a bunch of refactoring, cleanup, and generally addressing some of the things that make it difficult to get a releases out of the door. The Outrigger CLI is written in Go and the community has been evolving quickly. It is important for us to stay on top of that evolution in order to take advantage of new tools and approaches that make it easy to manage a technology.
For starters, we migrated to using `dep` for Go package/dependency management. We have also reorganized and linted the entire codebase using gometalinter. This allows us to keep a more stringent adherence to Go best practices for writing clear, concise and maintainable code. We have expanded test coverage to include gometalinter and a rig build & execution on every Pull Request.
The last big change was to integrate GoReleaser into the codebase and release workflow. GoReleaser, in a single command, allows us to: do a cross-platform build of the Outrigger CLI; create archives and Linux packages (and checksums) for release; create a GitHub release based on the newest tag; and automatically publish the Homebrew formula in our Outrigger Homebrew Tap for our Mac users. GoReleaser also allowed us to create a simple workflow for pre-release binaries to enable power user testing to ensure our releases are more stable than ever.
The path forward
We are really excited for this release of the Outrigger CLI. These changes will really help your teams (and ours!) stay on the same page and “take care of the easy stuff” while allowing you to focus on your clients and products.
In future releases we have plans to bring Outrigger CLI up to full Windows compatibility (everything works really well today with the exception of automated DNS configuration, PRs welcome!). We have changes to how we manage the Outrigger Docker Images and more plans to help move from Dev to Integration to Stage to Production.