1
In a scenario where the application is deployed for production through a pipe line run by an CI server, where the server performs the following tasks:
- Installs front end and back end dependencies. Performs other tasks defined in the task automator such as minification of files change in code and reduce image quality and videos.
- Runs the automated tests.
- Run migrations in the secondary database.
- Performs a dumping of the primary database server in production.
- Restores dumping of the primary database in the secondary considering the new data model.
- Updates files on application servers.
- Makes the secondary database primary and updates the old primary.
My question is this::
Considering that I am using a relational database, when running the database migrations it can not be in operation? (So I imagine I should update a secondary and then turn it into primary). In case I run the Migrations in a bank that is operating getting written bank to run my writing operations or will control them in an orderly manner through its competition control?
I am trying to find a safe yet decentralized methodology to evolve the database continuously close to the application, without relying on a team of Dbas, leaving the direct automated control on the CI and Deploy server, and the evolution of the bank to controlled in code by the developers themselves using classes of Migrations within the application.
I need tips based on the experiences of colleagues who have better experience with automated continuous evolution.