Why rerun?

Don't tools like chef and puppet for configuration management or mcollective, fabric and func for distributed execution already cover the bases when it comes to management procedure? The answer to that question is "Yes". So why introduce a tool like rerun?

During my travels through large mature enterprise organizations I see a not-so-uncommon need to enhance traditional shell scripting approaches and facilitate handoffs between teams.

Rerun is aimed more at organizational issues and not technical ones. You might find rerun useful for groups that have scripting skills but are unable to adopt a more sophisticated (and probably superior) alternative. Rerun can help bridge your efforts from ad hoc scripting to modularized formalized procedures that ultimately may be replaced by a more sophisticated tool or process.

Virtues rerun strives for:

• Stupid simple: The rerun implementation is one executable script.
• Clean interface. Put a standard calling syntax on your scripts.
• Modularity: Scripts are organized into rerun modules and commands.
• Low barrier of entry: In mature orgs, some teams can't foist ruby or python writing skills on other teams.
• Path of least resistance. For devs who hand over traditional scripts to the ops side of the house.
• Simple convention: Scripts (and optional metadata) are organized into simple directory layout.
• Development guard rails: Includes a tool to help create modules. The included "stubbs" module will help you maintain rerun conventions.
• No root user: Rerun does not assume you are running as root (and I would discourage it, if sudo can be used).
• Nice operating environment: Bash command completion makes it easy to list and use rerun commands (with a little color thrown in to boot).

If this effort strikes your fancy consider a Contribution.

Why the name?

Who doesn't find inspiration mining TV culture for a suitably campy yet short name for their open source project?

Next steps

← Home | Installation →