checklist
What Should You Check Before Calling a Staging Deployment Ready?
A staging preview is ready to hand off only when the build evidence, a short smoke path, the configuration list, and a rollback note all exist, and a person is named as release owner. ReleaseQuill can help assemble that packet from the repository and checks you supply. The checklist does not promote the app. Promotion beyond the preview environment requires separate authorization, and every published URL stays on our shared preview address, reserved for you.
What this question usually means
Teams search this when a preview exists and someone is about to say “ship it.” The rewrite cluster is: what evidence the build produced, which smoke tests ran, who reviewed configuration, where the rollback note is, and who owns the release. It is a readiness job, not a marketing page about hosting.
Staging here means the test preview you can inspect. It is not a promised production slot. If your organization uses “staging” for a long-lived shared host, still keep this checklist against the specific commit and URL in front of you.
Materials or prerequisites
Bring the repository and build commands, the preview URL, the health-check requirement, the environment variable list, and the name of the person who can authorize any later promotion. Bring the smoke path: one read-only user journey that must work on the preview.
If you do not have a smoke path yet, write one before you start the checklist. “It looks fine” is not an item you can tick.
Step 1: Attach build evidence to the commit
Record the commit hash, the command, the duration band, and whether the command exited zero. Keep the log path or paste. If the artifact is a container or a directory, name it. Evidence that cannot be found later does not count.
Step 2: Run a named smoke path on the preview URL
Open the preview. Hit the health check, then the one user journey you named — sign-in screen loads, a sample record appears, or a static page renders. Write pass or fail with the timestamp. Do not expand the smoke into a full regression suite in this checklist; that is a different job.
Step 3: Review configuration as a list, not a feeling
Walk the environment variables and any feature flags. Confirm required values are present, secrets are not printed in logs, and the preview is not pointed at a production data store unless that access is explicitly authorized. Write down anything that is still unknown.
Step 4: Complete the rollback note
The note names the previous working commit or the action that removes this preview, the data risk if any, and who can perform that action. If you cannot name those three, the checklist is incomplete even when the smoke path passed.
Step 5: Name the release owner
One person accepts that this preview was checked. That name goes on the packet. A checklist without an owner is a document nobody will defend tomorrow.
Verification
Hand the packet to someone who did not run the preview. They should be able to open the URL, see the same smoke result, find the rollback note, and say who owns the release. If they have to ask you what “staging” referred to, the packet is not ready.
Limits that stay on this checklist
Every app you preview stays in your own workspace, and each published link is one of our shared preview addresses rather than a hostname you control. Promotion beyond the preview environment requires separate authorization. Ticking this checklist does not promote anything and does not create a production SLA.
ReleaseQuill will not claim production availability, verified outcomes, or guaranteed results, and it will not claim a live connection to external platforms. Smoke evidence is what you recorded on this URL, not a guarantee about the next commit.
What ReleaseQuill does in this workflow
ReleaseQuill is for inspecting build and health results and recording the rollback path before anyone talks about promotion. Share the preview URL, the smoke path, and the configuration list in the conversation. The workspace can help you turn those into a single release record.
You still tick the boxes. The product does not mark a release approved.
FAQ
Questions this guide is for
How long should the smoke path be?
Short enough to run in a few minutes and specific enough to fail if the preview is empty. Health check plus one representative screen or request is enough for this checklist.
Who is the release owner if two people ran checks?
Name one. The other person can appear as a reviewer. Shared ownership with no name is how rollback notes get orphaned.
Does a passing checklist mean we can promote?
No. Promotion beyond the preview environment requires separate authorization. The checklist only says this preview was inspected.
Can ReleaseQuill promote my release to production?
Not by itself. Promotion beyond the preview environment requires separate authorization, and each published URL lives on our shared preview address scoped to your own workspace.
Start in the workspace
Assemble this staging packet in the workspace
Sign in or create an account. You return to the ReleaseQuill conversation. Bring the preview URL, smoke path, and rollback note, and keep a named owner on the record.