Reuse, release, and deploy
Build a release from one artifact
Promote the exact tested artifact instead of rebuilding independently in the deployment job.
9 minute lesson
The package job uploads the static site with provenance data; staging and production download that same artifact. That contrast gives us something useful to test instead of a rule to memorize.
Build-once promotion preserves the connection between tests, review, and the bytes that reach an environment. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.
The happy path can hide a bad design: you can run a fresh dependency install and build after approval, creating untested output and still get one successful demo. Push past the demo. produce one immutable artifact, record its source and digest, and promote it through environments, then test the condition most likely to prove the choice wrong.
The module is moving toward one outcome: Turn a verified build artifact into one controlled deployment with environment history and rollback. Save the before-and-after evidence now; it will make the final project review much more honest.
Compare artifact hashes in build, staging, production, and rollback records. Save the evidence, then explain which requirement would force you to choose a different design.
Lesson completed