¿Cómo debemos manejar las requestes de extracción en hotfix / * branches?

TL; DR – ¿Cómo puedo implementar Pull Requests para una twig creada dinámicamente?


Estamos utilizando un flujo de trabajo de gitflow modificado en TFS git, con el nuevo sistema Build de TFS 2015 para compilation y testing, y Octopus para implementaciones.

Tenemos la siguiente configuration:

  • master: publica una compilation de previsualización en nuestros serveres INT
  • release / v * – publica una versión de lanzamiento para QA -> UAT -> PREPROD -> LIVE
  • feature / * – construye y testing el código para las características. No se implementa en un entorno.
  • hotfix / v * – publica una versión de lanzamiento para PREPROD -> LIVE para revisiones urgentes

No hay twig de desarrollo. Bifurcamos las twigs de hotfix / v * de las tags que se crean cuando presionamos para lanzar / v * para reparar un entorno en vivo. Todo funciona realmente sin problemas … hasta que implementamos la security en "maestro", y aplicamos las Solicitudes de extracción para todas las twigs, excepto las twigs de function / *.

Se me ha pedido que habilite las relaciones públicas en los empujes para dominar, liberar / * y las revisiones / * twigs. El maestro no es problema, probablemente porque es una twig persistente; los otros tres types de twigs se fusionan en maestros una vez que se realiza el trabajo, y los RP funcionan muy bien para esto. Utilicé la API TFS REST para habilitar las políticas de bifurcaciones dinámicas en las nuevas versiones creadas / * y hotfix / *.

Sin embargo, nos enfrentamos a problemas de flujo de trabajo cuando intentamos hacer cumplir las RR.PP. para los cambios realizados en las twigs release / * y hotfix / *. Estas twigs son creadas dinámicamente por el desarrollador cuando son requeridas; el primer impulso del creador puede include cualquier cambio, y esos cambios luego se implementan en Octopus. Para una twig de publicación, esto generalmente está bien porque todo lo que hacemos es incrementar un número de versión en un file y presionar el cambio. Cualquier cambio adicional en la twig release / * requiere que el desarrollador cree otra twig fuera de la twig release / * (digamos releasefix / v1.1.2), para que puedan crear una RP en la twig de publicación. Esto es un poco incómodo (y ligeramente peligroso), pero un enfoque aceptable para nosotros.

El problema surge cuando queremos PR una revisión / * twig. El flujo de trabajo actual es el siguiente:

  • El desarrollador crea una twig desde la label de lanzamiento llamada "hotfix / v1.1.3", donde la versión es la versión EN VIVO + 1 incremento de parche
  • Desarrollador realiza cambios en la twig de revisión según la corrección requerida
  • El desarrollador empuja la twig de revisión de forma remota, lo que inicia la compilation y crea una versión de Octopus. Esta versión se puede promocionar libremente a PREPROD y LIVE sin que tenga lugar una revisión del código.
  • La twig de revisión / v1.1.3 luego se fusiona en el maestro, y cualquier versión / * twigs actualmente en existencia.

Además del ajuste estándar "Activar desencadenante" en una compilation TFS, TFS también tiene una política de código que nos permite ejecutar una compilation cuando se crea el PR, pero no después de que se atesting el PR (excepto en la twig que el PR se está fusionando en). las versiones release / * y hotfix / * se fusionan en master, pero tenemos que ejecutar la compilation de publicación en ambas twigs una vez que se apruebe el PR, ¡no antes!

¿Alguien tiene algún consejo? La única idea que tengo es eliminar completamente las twigs de revisión y mantener la última versión en vivo / * branch, con las revisiones fusionadas en ella. El problema que tenemos allí es que tendríamos que apuntar a un ciclo de vida diferente en el pulpo (PREPROD -> EN VIVO) para las revisiones, porque QA y UAT pueden estar siendo utilizados por otra twig de versiones.

Como nota al margen, TENEMOS que utilizar las twigs de lanzamiento / *, ya que podemos tener múltiples lanzamientos sucediendo en cualquier momento. Esto nos permite mantener correcciones de errores por separado para diferentes entornos: ir a la configuration de desarrollo / maestro de gitflow no nos funcionará, y parece un paso atrás.