You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In modern containerized systems, the presence of source code with migrations is not always guaranteed. This creates obstacles to running migrations in a separate step before deployment. It would be convenient to run migrations at will, for instance when an application starts.
The text was updated successfully, but these errors were encountered:
Some of the work has been done outside the framework in: #209 by @stefanhendriks
but there is a pressure to do this now that many projects moved on to Kubernetes and eliminating the migration step is preferred.
Basically, the idea is to keep the migrations files (SQL and Groovy) in the path of the app as resources. When an ll starts up, just execute the DB migration logic. This way, even if you have multiple nodes in the environment, the first node with non-executed migrations will execute the migration logic, and any following nodes will attempt to do the same, but will also detect that all migrations are up to date.
This approach eliminates the necessity to run the migrator my hand somewhere or in Jenkins. Simply deploy the new version of the app, and the first node with new migrations will execute them at the start.
In modern containerized systems, the presence of source code with migrations is not always guaranteed. This creates obstacles to running migrations in a separate step before deployment. It would be convenient to run migrations at will, for instance when an application starts.
The text was updated successfully, but these errors were encountered: