A real incident
Years ago I wrote a deployment script: delete old directory, pull new code, build, start. One day the build failed. The script stopped halfway — the live directory was already deleted and the new code was never built. The site was down.
Fixing it took twenty minutes. The lesson has lasted much longer.
Three rules
1. Every step must be re-runnable
A good script never assumes the last run finished. Conditions come before actions:
if [ ! -d '$TARGET' ]; then
mkdir -p '$TARGET'
fi2. Nothing is destroyed before the replacement is ready
The mistake was deleting first. Instead: build into a new directory, verify it, then swap symlinks. The old version is still there if the swap goes wrong.
ln -sfn /srv/app/releases/20261030-1 /srv/app/current3. Every run leaves a way back
Before any change, capture what can be restored. For a database that means a dump; for files it means a copy or a tag. A backup you have not restored once is a guess.
How to test it
Run the script, then deliberately break something in the middle and run it again. If the second run recovers instead of making things worse, the script is sound.
A script that only works when everything goes right is not automation — it is a wish.
Comments