← Engineering Notes

Release Engineering

Build once, verify, deploy

Fast deployment is useful only when the release can be identified, verified, and reversed. A small website benefits from the same discipline as a larger application.

Start with an identifiable artifact

The deployable unit should be built once from a known source state. Its contents are ordered consistently and file timestamps are fixed so identical source produces an identical archive hash.

The checksum becomes a compact identity for the release.

Use gates before production

Before deployment, internal links, canonical URLs, required files, legacy-content absence, security configuration, and artifact contents are checked.

A failed gate stops the release. Fixing the build is cheaper than debugging an avoidable production change.

Read production after deployment

An accepted deployment is not the same as a verified deployment. Public routes, redirects, 404 behavior, security headers, and the hosting file inventory are read back after cutover.

The previous verified artifact remains available as a rollback target instead of relying on memory or rebuilding an old state.

Catatan ini mendokumentasikan prinsip dan keputusan pada level publik. Detail sensitif, kredensial, data pelanggan, dan akses internal sengaja tidak disertakan.