java - tools - Cómo usar Flyway cuando se trabaja con ramas de características
flyway vs liquibase (3)
Recientemente hemos pasado a utilizar las ramas de características para cada historia en la que trabajamos. Estos son lo más independientes posible, y nuestro gerente de proyecto luego decide qué historias conformarán un lanzamiento. Esto significa que sabemos el orden exacto en que las historias entrarán en producción inicialmente.
¿Hay una manera estándar de lidiar con esto en Flyway? He leído las preguntas frecuentes que describen cómo el cambio a la base de datos de producción será lineal, lo cual es correcto. Sin embargo, no estoy seguro de cómo los miembros del equipo decidirían qué números de versión darían sus migraciones mientras trabajan en su rama de características. También deberíamos cambiar manualmente el nombre de los archivos de migración cuando nos fusionamos con nuestra rama de integración y master antes del lanzamiento.
La mejor manera que he visto para superar los problemas de versionamiento entre sucursales para habilitar outOfOrder y usar una marca de tiempo como número de versión
De forma predeterminada, la mayoría de los marcos de migración eligen prefijar las migraciones individuales con un entero, como se muestra en el siguiente ejemplo. Cuando el marco encuentra migraciones que aún no se han aplicado a la base de datos actual, comienza con la primera migración cuyo prefijo no está presente en la base de datos y comienza a aplicarlas en orden ascendente.
- 1.0.0.1__add_customers_table.sql
- 1.0.0.2__add_email_address_column_to_customers_table.sql
- 1.0.0.3__add_orders_table_with_reference_to_customer_table.sql
Esto funciona muy bien cuando todos están en la misma rama de código. Sin embargo, una vez que los miembros del equipo comienzan a trabajar en sus propias sucursales, la probabilidad de una colisión de prefijo aumenta dramáticamente.
Pero, si elige prefijar sus migraciones con marcas de tiempo en lugar de números enteros, la probabilidad de una colisión prácticamente desaparece, incluso entre las ramas. Por ejemplo, utilizando un patrón como yyyyMMddHHmmssSSS, las migraciones anteriores ahora parecen ...
- 1.0.0.20130704144750766__add_customers_table.sql
- 1.0.0.20130706132142244__add_email_address_column_to_customers_table.sql
- 1.0.0.20130706151409978__add_orders_table_with_reference_to_customer_table.sql
El patrón de marca de tiempo anterior es preciso hasta el milisegundo. Si bien una marca de tiempo altamente precisa puede dar lugar a prefijos difíciles de leer, cuanto más preciso sea su prefijo, menos probable será una colisión.
Para obtener los mejores resultados, querrá automatizar la creación de esta marca de tiempo para que todos los miembros de su equipo estén usando un formato consistente
Además, tenga en cuenta que Flyway también trata los prefijos de marca de tiempo como números enteros. Esto significa que si originalmente comenzó a trabajar con Flyway utilizando enteros, aún puede cambiar las marcas de tiempo en cualquier momento. Dado que las marcas de tiempo son solo enteros muy grandes, la primera migración con prefijo de marca de tiempo simplemente se aplicará después de la última migración con prefijo de entero.
Tomado de aquí y ligeramente modificado: http://www.jeremyjarrell.com/using-flyway-db-with-distributed-version-control/
No puede tener escrituras de migración con el mismo número de versión que obtendrá:
Se encontró más de una migración con la versión ''xyz'' (Delincuentes: SQL ...)
Aquí hay una solución que sugiero: varios desarrolladores están trabajando en la misma versión, digamos 1.0 pero en diferentes características. Supongo que está utilizando un rastreador de problemas que agrega identificaciones a cada problema, como FOO-16 . Cuando un desarrollador trabaja en ese tema, la secuencia de comandos de migración se llama V1.0.16__my_greatest_feature.sql . De esta manera (asumiendo que cada característica / rama tiene su propio problema) no hay colisiones.
También supongo que los scripts de migración de la base de datos son independientes y no se superponen, pero si este no es el caso, tendrá problemas al fusionar todo con una versión estable.
Así que en una versión estable tiene varios scripts de migración con huecos, por ejemplo: V1.0.16 , V1.0.27 , V1.0.101 (si se V1.0.101 FOO-16 , FOO-27 y FOO-101 ): a Flyway no le importa. Todas las características que no llegaron a una versión estable 1.0 (por ejemplo, V1.0.35 ) deben cambiarse de nombre para apuntar a la próxima versión principal (por ejemplo, V1.1.35 ).
Usar una marca de tiempo como una versión parece ser una buena idea. El único problema que veo es cuando el equipo se extiende por todo el mundo. En ese caso, podríamos tener que elegir una zona horaria como estándar.