.
IMO
Una pipeline que compruebe que los scripts de LiquiBase se han actualizado en Git para el entorno de test y prod.
En local puedes usar esos mismos scripts
Tengo mucha experiencia con liquibase y es mucho mejor que flyway. De todas maneras sigue teniendo sus pros y sus contras. Por mucho "database agnostic" que sea, siempre vas a tener tonterias (a no ser que las hagas desde el minuto 1) que no van a ser compatibles con diferentes bases de datos (como por ejemplo algunos tipos, quiza varchar?)
Recomiendo XML antes que los demas dado que puedes editar multilinea mucho mas facilmente (aunque tiene sus cosas tambien) y puedes incluir un XML dentro de otro, asi que puedes hacer un root con un include de todos los parches (o incluso mes a mes), y luego los parches cada uno por separado.
Si tienes cualquier pregunta con liquibase avisa, yo ahora lo estoy usando en un proyecto personal y va muy bien pero es un verdadero infierno cuando diferentes entornos necesitan diferentes esquemas, evita esto a toda costa.
#6 para cosas simples no lo veo mal, para cosas no tan simples no me parece lo correcto. Si quieres tener una pipeline o algo del estilo para esas cosas pues es obvio que no puedes tener el backend y la declaracion de la base de datos conjunta.
De todas maneras siempre suelo hacer una API por encima de la base de datos (hay incluso un proyecto que te monta una api por encima de postgres aunque no lo he mirado mucho) para separar lo que es la base de datos y la logica de negocio. Aunque tenga que hacer requests (a local incluso) para recoger los datos pero nunca uso la base de datos directamente desde mi aplicacion. Con esto, la aplicacion puede evolucionar de manera diferente ya que el contrato es la API en vez de la base de datos (como se guarden los datos me da igual)
#8 de normal me las pico yo a mano ya que no se tarda tanto en hacer 4 selects incluso con hibernate/spring boot. Tengo ya un esqueleto montado para este tipo de cosas. En este momento estoy picando el cliente que va a usar la aplicacion y que hace uso del modelo del que tambien depende la API, asi que tengo un modelo comun para el cliente y la api. (Lo siguiente es generar el cliente rest automaticamente con generacion de codigo aunque esto es algo que me llevara mas tiempo)
Como alternativa lo que decia: https://postgrest.org/en/v8.0/
1 mes después
#4 pues me sigue interesando.
En mi curro (ecosistema .net) equipos contiguos al mío están utilizando el sistema de migraciones de entity framework para las pipelines de CI. Estoy leyéndome los docs y parece bastante completito, aunque no me gusta tener un proyecto de .net donde se gestiona eso. La parte positiva supongo es que el proyecto en el que estoy no parece lo suficientemente complejo como para necesitar algo mucho más denso o rico en features. Aunque sí es probable que con el tiempo se tengan que tocar cosas bastante troncales al proceso de migraciones.
Alguien tiene experiencias que contar o algo que quiera compartir?
#10 la gracia de EF es precisamente esa, que tienes un proyecto de C# que te hace todo de una manera mas o menos automatica y los parches los aplicas en C#.
Yo como alternativa he usado proyectos de SQL que vienen a ser casi lo mismo pero picando las migraciones en scripts SQL.
Es un tema que puede ser todo lo complejo que quieras, puedes leer sobre Api Governance que abarca temas que incluyen tu situación
https://swagger.io/resources/articles/best-practices-in-api-governance/