From what I've read, migrations can be run separately from the application (dbmate), or as part of the bootstrap of the application (Flyway in the JVM).
I prefer the latter approach, yet most tools in python (and in general) use the former approach.
My intention is to build a docker image that once run, evolves the db/runs the migrations before building the db engine. But how?
When I build the docker image, I first build a skimmed venv that includes the sourcecode of my app and the runtime dependencies. Migration CLI tools like dbmate and alembic are not included. Besides, they don't read from the packages using pkg_resources nor importlib.resources, they're intended to be used on the workspace, not by the bundled running app.
I don't know if I'm overcomplicating stuff, so I'd like to know how to achieve migrations during the bootstrap of my application, and not as part of an independent pipeline or the deployment pipeline.
I prefer it that way given that when I'm running tests, I like running pg docker images and run migrations on them (using testcontainers). If I use the migrations as a "separate process", those tests are very complicated to get running.
If you think that such approach is very complicated, please state why, and share how it is usually done so that evolutions and deployment happen one after the other.