Deploy a website by identifying the exact release, checking its environment and dependencies, and verifying the delivered result before closing the change. Prepare the recovery decision alongside the release plan. A useful handover connects the reviewed artefact, target and observed public behaviour so another maintainer can explain what went live and how to respond if it fails.
Begin with the change’s intended outcome and the site it affects. Record the source revision or artefact, configuration, deployment identity and verification owner. Keep live deployment within its approved scope, especially where the same tool can target several projects or sites.
What exactly is being released?
Firebase Hosting’s resource guide supplies a concrete release model. Firebase Hosting channels serve specific content and configuration at an associated URL. A Hosting version packages content and configuration with a unique identifier. Use those documented concepts to identify the artefact and destination being reviewed.
A deployment creates a release that points to a version. Release metadata records who deployed and when. Retain the relevant identifiers in the change record so the review does not depend on a folder name or a screenshot whose source is unclear.
Keep the artefact and environment configuration distinguishable. A reviewed build may still need the intended service endpoints, domains and other settings. Ask the maintainer to explain which values belong to the release and which are managed separately in the actual hosting arrangement.
Use the project’s own build and verification scripts as the preparation route. Record their actual results before considering the live action. This article’s publisher example does not require a particular repository-hosted CI service or introduce an additional deployment platform for an existing site.
What should environment checks establish?
Firebase’s testing guide describes local preparation. Firebase Hosting can serve content and configuration locally for testing. The Local Emulator Suite can provide emulated Hosting content and configuration. Identify which parts of the proposed test arrangement are actually emulated or isolated.
The documented local app can use real project resources by default. Inspect the dependency and data routes explicitly before exercising actions such as submitting forms or changing records. An environment’s name should be supported by a verified configuration and approved sample-data arrangement.
Record the intended domain, service endpoints and deployment identity in the private operational plan. Check that the selected target matches the approved site. Keep credentials outside the repository and shared review transcript, using the organisation’s authorised automation route for the actual deployment.
| Release question | Evidence to retain | Decision it supports |
|---|---|---|
| Which artefact was reviewed? | Build/version reference and checks | Release content is identifiable |
| Where will it run? | Site, channel and relevant configuration | Target matches the approved scope |
| Which dependencies are used? | Actual service and data routes | Test actions have intended effects |
| What will be checked afterwards? | Representative URLs and workflows | Delivered result meets the change |
| How will recovery be decided? | Retained candidate and responsible owner | Response is defined before a failure |
This original release worksheet connects preparation to the approval and verification decisions. Adapt the fields to the actual hosting system, keeping the publisher-specific feature claims within their documented scope.
How should a reviewed preview become a release?
Choose a promotion route that preserves the intended artefact identity. Ask the maintainer to explain whether the operation reuses the reviewed version or builds a new one, and retain the relevant evidence. If the artefact changes, repeat the affected preparation checks before relying on an earlier review.
Cloning a Hosting version also deploys it to the target channel. Treat that documented operation according to its actual effect. Review the destination and obtain the required live authorisation before executing a promotion that serves content on the public route.
Prepare the verification checklist before release. Include the changed page or feature and representative adjacent journeys. Check the delivered body, relevant metadata, links and any essential form or account route included in the scope, using approved test information.
Record the actual observation from the intended destination after deployment. A tool’s successful completion is useful operational evidence, while the visitor-facing result still needs inspection. Keep both in the release record so an unexpected page or configuration can be investigated precisely.
What should rollback and recovery cover?
Retained live-channel releases enable rollback to a previous site version. Preview-channel rollback is not available in the documented Hosting workflow. Confirm the actual recovery mechanism for the destination involved instead of assuming every channel or hosting system behaves identically.
Identify the candidate recovery version and what it restores. Keep content/configuration recovery separate from any database, uploaded-file or external-service recovery required by the application. Ask each responsible owner to explain the affected state and the evidence needed before choosing that action.
Agree the conditions that lead to recovery, the person authorised to decide and the checks afterwards. A previous release can have its own dependency assumptions, so review its compatibility with the current environment. Retain any unresolved question in the change plan rather than presenting an untested recovery route as established.
Include a communication owner for an incident affecting the release. The operator needs to know who receives verification failures and where the evidence is recorded. That makes the response legible when several people are involved in the same environment.
Original release-identity and recovery exercise
Use a fictional website change in a separate test arrangement. Prepare a reviewed candidate, an identifiable earlier version and a representative page journey. The exercise follows artefact identity, target selection, delivered verification and a proposed recovery decision.
First, record the candidate and its configuration, then have another maintainer identify the intended target from the worksheet. Review the actual dependency routes and complete the agreed preparation checks. Resolve any mismatch before carrying out the authorised test deployment.
Next, deploy through the supported test route and inspect the intended destination. Compare the delivered page and workflow with the written expectation. Retain the release/version relationship and the observed result so a reviewer can trace the change without reconstructing it from memory.
Then exercise the approved recovery route in the test arrangement where supported. Inspect the restored content and relevant dependencies, recording what the operation changed. Keep any data or external-service recovery question assigned to its own owner.
Finally, review the evidence with the release owner and maintainer. Update the runbook with the demonstrated steps and unresolved assumptions before applying it to a later live change.
Include a fresh request to the intended public route in the release check. Record the destination and observed content so cached output or a different environment does not quietly become the evidence for the approved change.
For related work, see website development and hosting. Get started with the release target, verification journey and recovery requirements.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.