Cómo utilizar Flyway cuando se trabaja con ramas de características

Question

Recientemente hemos pasado al uso de 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 el que las historias entrarán en producción inicialmente.

¿Existe una forma estándar de manejar esto en Flyway? He leído las preguntas frecuentes que explican 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án qué números de versión dar a sus migraciones mientras trabajan en su rama de características. También necesitaríamos cambiar manualmente el nombre de los archivos de migración cuando nos fusionamos a nuestra rama de integración y master antes del lanzamiento.

Answer 1

No se puede tener scrtipts de migración con el mismo número de versión que obtendrá:

encontrado más de una migración de la versión 'XYZ' (delincuentes: SQL ...)

Aquí es 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ás usando algún rastreador de problemas que agrega identificadores a cada problema, como FOO-16. Cuando un desarrollador trabaja en ese tema, el script de migración se llama V1.0.16__my_greatest_feature.sql. De esta manera (suponiendo que cada característica/sucursal tiene su propio problema) no hay colisiones.

También asumo que las secuencias de comandos de migración de base de datos son independientes y no se superponen, pero si este no es el caso, tendrá problemas al fusionar todo en una versión estable.

Así, en una versión estable que tienen varios scripts de migración con lagunas, por ejemplo: V1.0.16, V1.0.27, V1.0.101 (si fueron escogidos FOO-16, FOO-27 y FOO-101) - Flyway no le importará. Todas las funciones que no llegaron a una versión estable 1.0 (por ejemplo, V1.0.35) deben renombrarse para dirigirse a la siguiente versión principal (por ejemplo, V1.1.35).

Answer 2

La mejor manera que he visto para superar los problemas de versiones entre las ramas para permitir outOfOrder y el uso de una marca de tiempo como el número de versión

Por defecto, la mayoría de los marcos de migración eligen anteponer las migraciones individuales con un entero, como se en el ejemplo de abajo 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 prefijos aumenta drásticamente.

Pero, si opta por anteponer sus migraciones utilizando marcas de tiempo en lugar de enteros, la probabilidad de una colisión prácticamente desaparece, incluso entre sucursales.Por ejemplo, usando un patrón como ddMMaaaahhmmssSSS las migraciones por encima de parecerse ...

• 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 conducir a prefijos difíciles de leer, cuanto más preciso sea su prefijo, menor será la probabilidad de que se produzca una colisión.

Para obtener los mejores resultados, usted querrá para automatizar la creación de esta marca de tiempo por lo que todos los miembros de su equipo están utilizando un formato coherente

Además, cabe destacar que la vía migratoria también trata prefijos de fecha y hora como enteros. Esto significa que si originalmente comenzó a trabajar con Flyway usando enteros, puede cambiar a las marcas de tiempo en cualquier punto. Como las marcas de tiempo son solo números enteros muy grandes, la primera migración con prefijo de fecha y hora simplemente se aplicará después de la última migración con prefijo entero.

Tomado de aquí y ligeramente modificado: http://www.jeremyjarrell.com/using-flyway-db-with-distributed-version-control/

Answer 3

El uso de 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, es posible que tengamos que elegir una zona horaria como estándar.