Build a deployment gate

A deployment gate is a script that decides whether code may ship. It runs checks in order, stops at the first failure, and records exactly which revision passed. A deployment wrapper should make policy visible rather than hide a chain of commands behind one optimistic message.

Gate a Node project

#!/usr/bin/env bash
set -euo pipefail

revision=$(git rev-parse HEAD)
printf 'testing %s\n' "$revision"

npm test
npm run build
git diff --exit-code

printf 'ready %s\n' "$revision"

set -euo pipefail is what turns a command list into a gate: the first failing command stops the script, so the final ready line prints only when everything above it succeeded.

git rev-parse HEAD captures the exact revision under test, and both messages name it. When someone later asks “what did we actually verify?”, the answer is in the output, not in anyone’s memory.

The sneaky check is git diff --exit-code. It exits non-zero when tracked files changed — which catches a build step that modified the working tree, like a formatter that rewrote sources or a generated bundle that should have been committed. If the tree changed during the run, you didn’t test what you’re about to ship.

Verify the gate closes

Introduce a failing test, a build error, and a generated change — one at a time:

./deploy-gate
# testing 4f2a9c81c2d0e7b356aa02cbf4f0b3a99d17c4e2
# ... npm test output ...
# Tests: 1 failed, 41 passed
printf '%s\n' "$?"
# 1

Confirm no later success message appears in any of the three cases. A gate that prints ready after a failure is worse than no gate, because people trust it and stop reading the output above it.

Test what you ship

The script exposes one more policy question: the artifact. This gate proves a revision passes checks — then many pipelines rebuild from scratch before deploying, and the second build isn’t guaranteed to match the first. Do not deploy a fresh rebuild different from the artifact you tested when the pipeline can preserve one artifact. Build once, test that build, ship that same build: hand the tested archive or image forward instead of rebuilding and hoping.