Measure twice, code once: Hardcoding dangerous scripts
Now here’s a trick for life when dealing with potentially destructive commands. Hardcode everything except the password.
Consider this script.
#!/usr/bin/env bash # initialize environment variables # source: http://stackoverflow.com/a/30969768 set -o allexport source .env set +o allexport # hardcode target because we do not mistakenly want to push to prod mysql --compress --verbose \ -u dbuser -p$STAGING_PASSWORD \ --host 22.214.171.124 \ staging-database < db-dump/dump.sql
The script above fetches the
$STAGING_PASSWORD from an adjacent
.env file, which is never added to the git repository. The script calls
mysql which imports a local database export into the staging database, and destructively overwrites its contents. This is how we can update the staging (test) database with a database export from the production (live) database.
A script like this should not be configurable.
Take it from me, accidentally deleting a database is painful. So, to spare the hair of me and my colleagues at Netlife, I choose to hardcode potentially dangerous scripts.