Record the composition of changes
Check the current version of the server and other pending changes. Prepare a proven set of files, dependencies, and migrations. Before deploying, save the required previous state outside of the public directory. For changes to the database, separately define compatibility with the old code and the possibility of recovery.
Continue with: Laravel project audits: what the owner should receive.
Prepare checks and rollbacks
Go through the scenarios in an isolated environment, agree on the signs of a failed release and the actions of the person responsible. Rolling back code does not necessarily undo a database change or an external operation. Risky migrations should be designed separately, and not hidden inside the general installation script.
Continue with: Website backups: prove that recovery works.
Check out the public version
After the release, check server responses, permissions for new static files, background processes, and required caches. First make sure that origin returns the new correct result, then clear the CDN. Otherwise, the old HTML or the error may be cached again. Write down the version of the release, the time, the result of the checks and the backup location.
Is it enough to refresh the page in the browser?
No. Browser, CDN, server cache and PHP may have different update dates. You need to check the actual public response and functionality.