Safe update: deploy lock, snapshot, check and rollback
Updating Conn2Flow gained a lock against two deliveries at once, a backup of what is about to be replaced, a check after the swap and an automatic restore when something breaks.
Two deliveries at the same time on the same server, or a delivery that breaks the installation, were the two most expensive deploy accidents. This batch of changes deals with both.
Before the swap
- Deploy lock: created atomically, with an owner and a time limit. A second delivery to the same destination waits or is refused, and is told who holds the lock.
- Migration check: a duplicated version or class across core, project and plugins stops the pipeline before any change.
- Selective snapshot: stores only what the plan will overwrite or remove; the five latest snapshots stay available.
- Database dump before the database step.
After the swap
The installation is checked: a new fatal error in the PHP log, or an HTTP 500 on the root, fails the delivery. When it fails, the files come back from the snapshot and the updater exits with a code of its own. The database does not come back by itself: restoring the dump is an explicit decision.
A per-layer manifest records what each owner (project, plugin, core) installed, with the precedence project > plugin > core.
Status
Validated on an isolated tenant, including a deliberately broken delivery. Final acceptance pending.
Source: Core · req-197 and req-198 · BATCH-201 to BATCH-204