How to safely deploy a project with migrations?

Question

JavaScript

Hello!
Faced the problem of the incapacity of the project during the calculation with new migrations. Suppose you need to roll a new build with changes in the database in the form of migrations, the laid out code naturally uses the new database structure. Because some migrations can take a long time to complete (adding fields to a large table), the project does not actually work correctly at this time. We have migrations as part of the project and are laid out along with the code.
It became interesting how this problem is solved in practice? The first thing that comes to mind is to create migrations in a separate branch (we use git), first apply this branch, make migrations, and only then upload the build. Is it too cycling?

Answer 1

Typo in function name: dargStart -> dragStart

Answer 2

this.className += 'hold';
no space

Answer 3

For intensive changes in the structure of a large database, use replicas.
We have a pair of master slaves. If you need to update the schema:

• disable slave
  
• run migrations on it
  
• make it a master and connect a new slave to it
  
• update the project code if necessary
  
• switch it to the new master
  
• disable former master
  

Answer 4

I don't think there is a universal solution here. It all depends on how many "services" use your database, how idle each of them is allowed, and how flexible your code is.
You can imagine that migration is a change in the presentation of data. Thus, we have a potential opportunity to use the view, and work from the code not directly with the data, but with these same views. That. You can create new temporary columns, target the view to them, and populate them with a trigger, for example.
In mysql 5.6 (not even 10 years!, or has it been?), if you just change the name of a column, copying to a temporary table with the appropriate lock does not happen.
That. if you wrap in a single transaction (with a lock) renaming a column, and targeting the view back to the "original" name of the column, you will probably be able to achieve minimal downtime.
Migration, so becomes a multi-move, but you save yourself the fear of losing data after the migration curve and make it easier for yourself to switch between old / new data, because you control this from the migrations code.
view has many limitations in the case of "complex" queries, joins, you must have the appropriate indexes for the view to work on them, etc.
I think you should estimate the complexity of the operational work to implement this solution, and the solution described by Fortopa little higher. And understand what you can give up, and what is easier to implement in your system now, and in 1 year.