A web release contains more than a homepage. Changed routes, canonical links, navigation edges, sitemap entries, redirects, and the CMS snapshot form a page graph that a visitor and crawler traverse. A smoke test should check the routes affected by the release, verify that their links resolve, and confirm the expected revision. An earlier frontend artifact can be restored quickly, but it may not understand newly published fields or slugs. Maintain a compatibility window and decide whether the recovery action is artifact rollback, CMS correction, cache bypass, or a forward fix. Keep the release record tied to a deployment ID and content snapshot so the team can explain the public state.
Make this comfortable
Web release rollback: check the page graph and preserve content state
Operational decision
A release adds 12 DevOps lessons and changes 4 existing related-lesson cards. The smoke job tests those 16 routes, the DevOps index, and the navigation paths that expose them. It rejects broken internal links, duplicate canonical paths, and a mismatch between route revision and the expected CMS snapshot. After a faulty frontend template is found, traffic returns to the prior artifact. The operator checks that this artifact can still render the 12 new records; if not, it temporarily hides those routes or publishes a compatible forward fix. It also checks edge cache entries created by the faulty template and records any CMS edits that need independent repair. Recovery is finished only after public probes pass.
Release 84 smoke scope
Changed lessons: 12
Changed related cards: 4
Shared index: 1
Checks: status, marker, canonical path, internal links
Rollback candidate: prior artifact plus current CMS snapshot
Recovery evidence: public probes pass after cache windowCost and verification
For V changed pages and E internal links on them, a direct graph smoke costs O(V + E) requests before retries and caching effects. Full-site checking may be suitable overnight, while release gates should cover changed pages plus shared hubs and high-risk routes. A rollback control-plane action may be fast; repair cost grows with incompatible content records and stale caches. Measure broken-link count, missing-route count, CMS-to-public lag, and time until the user path is healthy again.
Common Mistakes
- Do not declare recovery when only the homepage loads.
- Do not assume a frontend rollback reverses CMS state.
- Do not ignore cached redirects and index pages after a route change.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Web publishing evidence: prove the build, deployment, and live route separately
- Published content caches: bound the stale window and purge the right key
- Serverless rollback: restore code traffic without assuming data rolled back
Practice and check
Browser and edge security follow-up
devops
web-publishing