Static Site Delivery

Behaviour#

Deployment is five steps, and make deploy is all five. They live in one script that is short enough to read before running it, and the make targets are one-line wrappers that pass ENV through.

plan and destroy stop after init (and workspace selection): plan prints the change set, and destroy removes everything, bucket contents included, because the stack bucket sets force_destroy.

Roots#

Each ENV maps to a Terraform root. Every root composes the same published module at the same pinned version, so they differ only in backend, domain, and credentials.

The workspace root is the only one that selects a Terraform workspace. Its name comes from DEPLOY_WORKSPACE, then the CI branch name, then the local username, which is how each developer gets their own state, bucket, and hostname — see Derived Developer Identity .

Examples#

Root selection and the developer workspace are resolved before any command runs:

case "$environment" in
	workspace) root=workspaces/site ;;
	staging) root=env/staging/release ;;
	prod) root=env/prod/release ;;
esac

terraform -chdir="$root" init -input=false

if [ "$root" = workspaces/site ]; then
	terraform -chdir="$root" workspace select -or-create \
		"${DEPLOY_WORKSPACE:-${GITHUB_REF_NAME:-$(id -un)}}"
fi

Day to day, the make targets are the interface:

make deploy                 # your own copy
make deploy ENV=prod
make deploy.plan            # preview, changes nothing
make deploy.destroy         # tear the instance down

Rolling back is the same command run from an earlier commit: check it out and make deploy again. The bucket is versioned, so earlier object versions stay recoverable even without the pipeline.