Implementación de repliegue de Capistrano y enigma de migraciones de Phinx

Estamos usando Gitlab CI y Capistrano para administrar nuestras implementaciones. Las migraciones se almacenan junto con el código en el VCS (Git). Todo funciona bien cuando se envían nuevas confirmaciones con nuevas migraciones.

Digamos que hemos confirmado A con la migration A, luego confirmamos B con migration B. Ambas han sido desplegadas sucesivamente a la producción. El Commit B B introduce un error importante, por lo que queremos revertir la producción al estado en el que se encontraba con commit A.

Actualmente, tenemos dos forms de hacerlo: implementar roll roll rollback o volver a implementar commit A con Gitlab CI. Favorecemos el networkingiseño de CI de Gitlab, ya que podemos retroceder tanto como queramos, mientras que Capistrano está limitado por la configuration de keep_releases. Gitlab CI también proporciona buenas herramientas para saber qué compromiso se implementa actualmente en cada entorno.

tapa desplegar retroceso

Me imagino que debería hacer que Capistrano retroceda a la migration A antes que nada. De esa forma, podría funcionar:

php vendor/bin/phinx migrate -t migration_id 

en la base de código de confirmación B, y no falta migration. Pero, ¿cómo puedo adivinar migration_id? Debería ser la última migration disponible en la confirmación A.

Gitlab CI reintroducción

Gitlab CI lanzará Capistrano para volver a implementar el compromiso A para la producción. En algún momento, Capistrano correrá:

 php vendor/bin/phinx migrate 

en commit A codebase, por lo que la migration B falta y no se puede revertir.

¿Cómo debería lidiar con esto? ¿Alguien está enfrentando el mismo problema? ¿Estoy pensando demasiado en esto? ¿Debo simplemente deshacer manualmente las migraciones antes de volver a implementar la confirmación A?

Gracias por llegar hasta aquí.