How to properly deploy a project in php?

Question

PHP

What is used:
Laravel (nginx + php-fpm + mysql) + git
Laravel migrations are used for database changes.
How to apply migrations without 5XX errors?

1. Suppose a column is deleted from the table - no problem, we tighten the commit with code that does not use the column -> run migrations
   
2. Suppose a column is added to the table - split the deployment into 2 commits?
   
   1. with a migration that will just add a column
      
   2. with the code that uses it
      
   
   
3. Suppose the relationship from hasMany has changed to manyToMany - also split into 2 commits?
   
   1. adds a table that links 2 other tables, transfers the relationship
      
   2. code that already works with manyToMany + migration that removes the hasMany relation. Here you need to take into account that between the deployment of the first and second commits, new records may appear, do they need to be tracked at the base level (triggers)? and delete it when deploying the second one?
      
   
   

If the site is normal, then you can not break it into commits, close the site (php artisan down) -> run migrations -> open the site (php artisan up)
If the project is used as an api, then this method will not work.
How are these problems usually solved?

Answer 1

To solve this problem, it is required to ensure backward compatibility of release versions. In other words, all new changes should not break the old code. The general procedure for deploying a new version occurs in 2 stages:
1 - applying migrations and raising the new version in parallel with the old one,
2 - the old version stops accepting new requests and stops when it finishes processing existing connections (graceful shutdown).
Regarding the examples given
1 - absolutely true, there are no problems
2 - not necessarily, because in the process of deployment, new and old code can work at the same time
3 - if we are talking about the impossibility of implementing backward compatibility, then this problem should be avoided at the level of architecture and planning. It does not have a beautiful solution, but there are options, or a complete shutdown of the system will be required to apply incompatible migrations. Or an implementation is required that will allow two versions of the code and the base to work, with the ability to manually synchronize changes that occurred with the old version at the time of deployment.

Answer 2

I recommend looking towards Docker.
Deploy the services that are used in the container.
When deploying, images of services are collected in a container,
scripts are worked out for statics (if necessary) and migration.
Changing the container takes a fraction of a second - this will be the downtime.
This is the fastest way I know of to upgrade to production.

Answer 3

In one place, one of the requirements I had was to prepare a deb package with scripts for the initial installation and update (there was no classic base there, but the point is to update it too if necessary), and it was necessary to guarantee that the deb would correctly update from any previous version (this is easily solved by sequential execution of the scripts of each intermediate version, not so effective, but definitely). A rollback to a previous version was not required.