Repeatable delivery, with a lock, a copy of what will be replaced, a check after the swap and automatic rollback when something fails.
Publishing a project is not copying files. It is compiling resources, synchronising the database and rebuilding the CSS, always in the same order.
The core is synchronised first; then the project resources, which may override the core ones.
Compiled resources enter the database by natural key, and pending migrations are applied.
Each page's CSS is recalculated from the HTML in the database, so a new page is never served with the old style.
One delivery at a time. A second attempt midway is refused.
What will be overwritten is copied first, along with a database dump.
Files and database are updated following each layer's manifest.
The installation is tested after the swap.
If the check fails, the snapshot files come back on their own.
Implemented and validated on an isolated test tenant, with an artefact broken on purpose to exercise the automatic rollback.
Every live installation ends up with files that differ from what the delivery brings. The system records the conflict instead of overwriting silently.
Overwrite, keep or merge, file by file, from the panel, the API or the CLI. "Keep" becomes a rule and does not ask again.
One call starts the same updater the CLI uses, answers at once and lets you follow the status, the snapshot and the end of the log.
HTTP APIThe reverse path: bring into the repository what was changed in the running environment, through the same conflict engine.
Conn2Flow is the tool. If you need the Architect to design your company's strategy using this technology...
Hire Specialized Consulting