Rerun: Making shell scripts even more useful (and a bit cool, again)
Damon Edwards /
I recently made a couple of additional videos about the curiosity that is the Rerun project. You can find them below.
The conventional wisdom on shell scripts is that… well… “shell scripts suck”. But why? Shell as a language is extremely powerful and useful but shell scripts can quickly become unwieldy when trying to use amongst a team or in long-lived operations. But what if you had a framework that solved the team-level problems and the lacking of standardization while letting you use the full power and familiarity of shell? Enter Rerun, a simple tool that turns your favorite shell scripts into modular automation that has standardized options handling, command line completion, documentation generation, and a built-in test framework. Suddenly shell scripts don’t suck so bad anymore.
Why am I so interested in Rerun? Because I’ve seen Rerun have a positive effect on a very real human problem: In most non-startup organizations, the DevOps divide is made worse by a mismatch of skills, tools, and technologies.
It’s common for the Ops team to have used a tool like Puppet to automate server config and image building. But when it comes to app deployment and config, the various app teams don’t have the Puppet skills or motivation to follow suit. So each app team picks their own tooling or glue language. Of course, this just confuses Ops and makes their lives more difficult. Sometimes there will be a centralized release team (often now awkwardly rebranded as the “DevOps Team”) that will attempt to pick their own solution. But, neither Dev nor Ops ends up bring happy with the choice and the “DevOps Team” is now the bottleneck in the middle. Lots of noble DevOps intentions die in scenarios like this.
The effect of Rerun is that everyone can now come to the table on equal footing and use shell as their lingua franca. They can learn to collaborate using a simple framework for the “glue” that holds things together (of course, Ops still builds server images using a config management tool and Dev still builds their apps the way they want to). The built-in documentation generation and test automation framework makes handoffs easier. Everyone knows the simple command and options interfaces, but can also read each others code if need be (it’s just shell scripts, after all). Once you get everyone engaged and contributing to bridging the DevOps Gap, you can collaboratively start to look to other newer, specialized solutions.
I have to get Rerun’s creator, Alex Honor, to do a full post on Rerun. In the meantime you might find these videos interesting:
Video 1: Chuck Scott gives a tour of how he uses Rerun to turn his “keeper scripts” into reusable, standardized, test-driven automation
Video 2: Group discussion with Anthony Shortland, Lee Thompson, Chuck Scott that looks at an example of a DevOps toolchain automated with Rerun
– “everyone can now come to the table on equal footing and use shell as their lingua franca”
– “it’s just shell scripts, after all”
Telling my dev team “it’s just scripts” is like telling them to step into a tornado while exclaiming “it’s just wind!” The few who do use Cygwin only use it if absolutely necessary, and even then it’s only a few high-level commands for niche cases.
I will certainly give it a whirl for “standardized options handling, command line completion, documentation generation, and a built-in test framework.” However, I still don’t expect dev to get their hands dirty with the scripts or gain much insight into what I do.