Zhihe GrowthDefine the consistency problem
Prepare a complete version directory before switching the serving pointer. Retain the old version for rollback. This limits intermediate static-file states; it does not make databases, CDN edges and browser caches part of one transaction.
A browser may retain old CSS under a stable asset name after the server pointer changes. Versioned assets or cache policy need separate design. Local filesystem atomicity does not mean every visitor sees the same global state simultaneously.
What the executed experiment does
controls.py creates temporary v1 and v2 directories with page and style files. It points current at v1, atomically replaces the pointer with v2, injects a verification failure and switches back. It records v1, then v2, then restored v1.
| Checkpoint | Result | Scope |
|---|---|---|
| Before switch | v1 | Initial version |
| After switch | v2 | New pointer active |
| Injected failure | true | Authored failure condition |
| After rollback | v1 | Previous pointer restored |
| External CDN check | Not performed | Outside local experiment |
| Database restore | Not performed | No database writes |
The experiment uses no production connection or credentials and does not alter a real site. It is a runnable teaching example, not a complete deployment product.
Know exactly what may change
Create an allowlist of pages, routes, language maps, styles and assets. Compare the current production tree with the release baseline. If WordPress or another operator has published since capture, reconcile rather than overwrite their work.
A backup must cover affected state and be readable. Static files, databases, configuration and client submissions may need different recovery policies. Public logs can record backup completion without exposing private contents or access details.
Coordinate concurrency and version approval
Prevent concurrent pointer changes. Define lock scope and avoid calling a nested check that needs the same lock while already holding it. Approval must bind the actual package; changed inputs require revalidation.
Copying the current release and applying an allowed overlay preserves unrelated CMS content only if concurrent changes are also detected. Verify hashes and the current pointer before activation. Idempotency supports retries, not bypassing approval for new work; see the state machine.
Verify after the switch
Fetch public home and directory pages, new bilingual articles, sitemaps, images and downloads. Check status, hashes, indexing instructions and rendering. Protected administrative and client areas should retain their existing controls. Uploaded downloads can still be blocked by server filename rules.
Before rollback, verify that the active release is still the one being tested so another operator's later work is not undone. Record failure, restored version and recovery checks. A static-page error should not trigger an unrelated database restore that removes new client submissions.
Zhihe Growth's evidence boundary
Report backup, activation, public acceptance and search observation separately. Going live is not indexing or AI citation. Public update logs should describe actual content changes without publishing internal infrastructure details.
The local fault exercise explains a reliable design. Real client deployment needs adaptation to the operating system, web server, CMS and permissions, plus a recovery test. Engineering credibility comes from repeatable execution rather than describing a demo as an autonomous production platform.
Rollback decision table
| Question | Verify | Do not assume | If missing |
|---|---|---|---|
| Old version exists | Readable files | Backup name means recovery | Stop activation |
| Active release is ours | Pointer and hashes | No concurrent publisher | Reconcile conflict |
| Database changed | Actual change list | Static update means all state | Separate recovery |
| Download permitted | Public request | Local file is enough | Repair affected asset |
| Cache consistent | Response and asset versions | Pointer restores all clients | Inspect cache policy |
| New client data preserved | Protected storage untouched | Full restore is always safe | Avoid unrelated data |
Use identifiable version contents and read them before, after and after recovery. A printed success message is not verification. Public teaching code should remain confined to temporary directories; real server paths and credentials belong in controlled operations material.
Materials and reference
Download the switch-and-rollback experiment. Pair it with content CI and HTTP diagnosis. Google's HTTP status documentation provides crawl-response context.