In Praise of --no-dry-run

There are scripts that are designed only be run a handful of times, or maybe even once under rare circumstances. They are usually tested a lot of more times than they are intended to be executed, or when they are executed, their actions could be detrimental, this is where --no-dry-run option comes in.

In my career, I seem to have worked on a lot of system, or application migrations. I’m not sure if this is very common outside of the places I’ve worked at or if I’m just a harbinger of change. Depending on the migration the approach changes but there usually comes a time when a cut over to the new solution needs to be done. The steps leading up to, during and after the migration are typically crucial with rollback procedures in place in case something goes wrong. These steps would have been tested thoroughly before hand by mocking the system in various states. But here’s the thing, the actual cutover happens once. To prevent prematurely executing the script it’s nice to have a second layer of acknowledgement, the --no-dry-run option.

In addition to having the operator being cognizant of the command they’re about to run another benefit of implementing a --no-dry-run option is it grants an opportunity to report on the current state of the system and the changes that would have been applied. The number of records in the database that would have been copied, the IP addresses on the VMs that would have been changed or the files in the shared drive that would have been deleted, you get the point. The operator can then evaluate if the current state of the system is as expected, the actions that would have been performed were within the tolerances defined and only then execute the same command with --no-dry-run.

While there are situations where this works great, it’s not a solution for every script. Having to include the --no-dry-run option on every invocation of rm, cp or mv would be incredibly annoying. On the other end of the specturm when working in a system with complex states and interfaces for change using --no-dry-run might not be the best solution. In these cases following a plan and execute pattern would work better, this is typically something you see of Infrastructure-as-Code frameworks like Terraform of CloudFormation.

This was written in response to Henrik Warne’s post, In Praise of –dry-run, which I discovered through Hacker News. A good read and if you aren’t using --dry-run, maybe it’s time to consider it. I think the first time I ever encountered this option was when using rclone to move files around different remote storage locations.