This will require a restructuring of how we store project code on servers.
Basically there would be 2 (or 3) copies of a project on a "production" server at any given time.
There are three relevant locations (none of these names are final):
~/projectroot (hold the git clone)~/live (holds an rsync copy of the project root from the last "deploy")/var/www (symlink to ~/live)
When you run an "update", you git pull to update ~/projectroot, but that's not "live" so nothing changes yet. Then you rsync the entire folder into a new ~/staging folder, run composer install and whatever else there, and if that all succeeds, move the symlink to point to it.
Then you have a "rollback" target still in the old ~/live folder that's only a symlink (and maybe migrations run down) away.
This will require a restructuring of how we store project code on servers.
Basically there would be 2 (or 3) copies of a project on a "production" server at any given time.
There are three relevant locations (none of these names are final):
~/projectroot(hold the git clone)~/live(holds an rsync copy of the project root from the last "deploy")/var/www(symlink to~/live)When you run an "update", you
git pullto update ~/projectroot, but that's not "live" so nothing changes yet. Then you rsync the entire folder into a new ~/staging folder, runcomposer installand whatever else there, and if that all succeeds, move the symlink to point to it.Then you have a "rollback" target still in the old
~/livefolder that's only a symlink (and maybe migrations run down) away.