Flujo de trabajo que impone la revisión del código y mantiene la twig de integración prístina (git, Stash, TeamCity)

Estoy tratando de diseñar un nuevo flujo de trabajo que siga estos principios:

  • Solo las confirmaciones que hayan pasado la verificación automática (IC) se deben fusionar en la línea principal (específicamente, el estado fusionado debe pasar CI para mantener la twig de integración tan prístina como sea posible)
  • Solo los commits que hayan pasado la revisión del código humano deberían fusionarse en la línea principal.
  • Solo los commit que han pasado la verificación automática deben ser revisados ​​por otro ser humano (si ni siquiera se comstack y pasa las testings, no pierdas el time de otra persona)
  • Las twigs de características deberían estar cubiertas por CI (independientemente, no fusionadas en la twig de integración, esto es útil para desarrolladores durante el desarrollo)

Estamos usando git, Stash y TeamCity. Esto es lo que se me ocurrió, pero ninguno de ellos es perfecto. Estoy buscando ajustes a mis sugerencias o nuevas ideas.

FLUJO DE TRABAJO 1

  • El desarrollador se desarrolla en la característica / VHPC-1 (las twigs de function están cubiertas por CI normal en TeamCity)
  • Cuando se completa la function, el desarrollador crea una request de extracción: feature / VHPC-1 -> mainline
  • Cuando la request de extracción es aprobada por otro desarrollador, Stash la fusiona automáticamente en la línea principal (la línea principal está cubierta por un CI normal en TeamCity)

  • Problema: Stash no realizará la fusión si hay conflictos de fusión, pero el estado fusionado no se testing para nada hasta después de la fusión con la línea principal. No sabemos si la línea principal se romperá hasta que lo haga.

FLUJO DE TRABAJO 2

  • El desarrollador se desarrolla en la característica / VHPC-1 (las twigs de function están cubiertas por CI normal en TeamCity)
  • El desarrollador empuja desde la característica / VHPC-1 a la function / VHPC-1 / revisión (donde volvimos a establecer la base de la twig de integración y luego hacemos CI (probando el estado fusionado))
  • Cuando se completa la function, el desarrollador crea una request de extracción: feature / VHPC-1 / review -> mainline
  • Cuando la request de extracción es aprobada por otro desarrollador, Stash la fusiona automáticamente en la línea principal (la línea principal está cubierta por un CI normal en TeamCity)

  • Problema: el time (20 min – 1 día?) Entre el estado fusionado se testing y la integración ocurre, permite cambios en la twig de integración, lo que podría significar que el estado fusionado ya no funciona. Posibilidad de que la twig de integración se rompa.

  • Problema: el doble de twigs implica un trabajo y una complejidad adicionales.

FLUJO DE TRABAJO 3

  • El desarrollador se desarrolla en la característica / VHPC-1 (las twigs de function están cubiertas por CI normal en TeamCity)
  • Cuando se completa la function, el desarrollador crea una request de extracción: feature / VHPC-1 -> feature / VHPC-1 / review
  • Cuando otro desarrollador atesting y fusiona la request de extracción, la característica / VHPC-1 / revisión se comstackrá y probará automáticamente en el estado fusionado y se transferirá automáticamente a la línea principal en caso de éxito.

  • Problema: el doble de twigs implica un trabajo y una complejidad adicionales.

  • Problema: los errores siempre deben estar integrados en la línea principal, y solo deben ser seleccionados para liberar twigs.

FLUJO DE TRABAJO 4

  • El desarrollador se desarrolla en la característica / VHPC-1 (las twigs de function están cubiertas por CI normal en TeamCity)
  • Cuando se completa la function, el desarrollador crea una request de extracción: feature / VHPC-1 -> mainline TeamCity se agrega automáticamente un revisor e intenta crear y probar la request de extracción en el estado fusionado (utilizando los refs / pull indocumentados de Stash -request / merge)
  • Si se atesting la verificación automática, TeamCity aprobará la request de extracción. Un humano puede luego revisar, aprobar y fusionarlo en la línea principal.

  • Problema: TeamCity monitorea refs / pull-requests / merge, que cambia cuando la twig de integración cambia, lo que significa que se generará una compilation en todas las requestes de extracción abierta cuando la twig de integración recibe un cambio nuevo.

ex desarrollador de Stash aquí. Solo algunos pensamientos generales.

El equipo de Stash (y la mayoría de los equipos con los que he trabajado y observado) realizan construcciones de sucursales "optimistas". Es decir, construyen la twig fuente bajo la suposition / esperanza de que si se fusiona limpiamente, probablemente no romperá la construcción principal. Y en mi experiencia esto es casi siempre el caso.

Algunas opciones:

  1. No hacer nada, si / cuando la línea principal eventualmente se rompe, soluciónalo rápidamente
  2. No haga nada más que revertir automáticamente cualquier compromiso de fusión que produzca una compilation roja (y posiblemente hacerlo manualmente para comenzar)
  3. Requerir que las fusiones de relaciones públicas sean de avance rápido, y los desarrolladores necesiten volver a fusionar / fusionar manualmente desde la línea principal antes de volver a fusionarse
  4. Agregue un button / complemento de controller de acceso personalizado en Stash a todos ustedes para "Combinar en compilation verde después de la integración", que hace una compilation de fusión única antes de realizar la fusión real.

Estoy de acuerdo con que, en general, build desde la reference oculta 'fusión' de Stash, dependiendo de cuánto time estén abiertas sus requestes de extracción, probablemente resultará en demasiadas construcciones (como usted señaló).

No estoy seguro si eso ayuda?

Recomendaría Workflow 4 pero con ligeras modificaciones

  • Ejecute CI en todas las twigs de características siempre que haya un check-in. Informe los resultados a Stash utilizando el complemento teamcity-stash

  • Habilite Stash para hacer una fusión automática cuando haya al less

    • x cantidad de aprobadores
    • y número de comstackciones exitosas.
  • Cuando un desarrollador está listo, puede crear una request de extracción en la línea principal
  • Ejecute CI en todas las requestes de extracción e informe este estado a teamcity. La ventaja aquí es que cada vez que se atesting una request de extracción, git fusiona automáticamente esa confirmación en otras requestes de extracción y, por lo tanto, vuelve a activar el CI en todas las requestes de extracción.
  • Una vez que los revisores y los aprobadores atestingn el código y las requestes de extracción han pasado con éxito a CI , el alijo unirá automáticamente la request de extracción.
  • Ejecute su compilation y testing en cada check-in en la twig de integración para que pueda identificar qué check-in comenzó a fallar en alguna testing específica (si tiene algún límite de tolerancia para las testings)