A build is an artifact. A release is an artifact placed into an environment where people depend on it. Treat those as different events.
Before building
- Review the content diff, including machine-readable outputs.
- Confirm that source files contain no private data or credentials.
- Record the commit and the exact Hugo version.
- Validate node identities, vocabulary, and relationships.
- Confirm the production base URL and included content selection.
Do not enable draft, future, or expired content indiscriminately in a production build. A published expression must not point to an excluded graph target.
Inspect the artifact
For a standard Hugo build:
hugo --gc --minify --panicOnWarning --baseURL https://your-domain.example/
Replace the example domain. Check the generated HTML, JSON, RSS, sitemap, and 404 page—not just the terminal exit code. Follow internal links from a local preview of the built artifact. Verify assets under the intended deployment path.
For this repository, the documented scripts/check.py command adds graph and
output checks before release.
Inspect the deployed system
Host behavior cannot be proven by a local Hugo build. Verify HTTPS, redirects, cache headers, the actual 404 status, robots behavior, and canonical URLs on the chosen host. Do not claim those checks passed before there is a deployment.
Keep the last known-good artifact or deployment identifier. The recovery path should not depend on reproducing an old environment during an incident.
Make rollback ordinary
A release note should identify the commit, artifact, changed behavior, and how
to restore the previous release. Prefer a reversible deployment mechanism. For
source changes, git revert creates an explicit undo without rewriting history;
understand the affected commit before running it.
Try it: write the rollback step before the deploy step. If it is vague, the release process is not ready yet.