¿Cómo se ve su flujo de trabajo ágil, en particular la frecuencia de publicación y la administración de control de fuente?

Mi equipo está discutiendo la forma más eficiente de administrar los lanzamientos para nuestros usuarios. Este es nuestro flujo de trabajo actual para nuestros ciclos de sprint de 2 semanas:

  1. Desarrollamos todo en el maletero
  2. Tenemos una compilation nocturna de Team City que empuja a nuestro server Nightly Build
  3. Nuestros BA / QAs evalúan las comstackciones nocturnas y deciden cuándo promocionar a QA / UAT
  4. Al final del sprint, empujamos todo lo que está en el tronco a UAT.

El mayor problema que estamos viendo con esto está relacionado con todo lo que se está desarrollando en trunk. Debido a que las historias incompletas se registran en el enlace troncal , nuestras comstackciones nocturnas ocasionalmente tienen errores. Este escenario también puede ocurrir al final del sprint, por ejemplo, una historia que consta de 6 tareas (de las cuales 3 están completas ) se ha registrado en el enlace troncal.

Soy de la opinión de que un usuario solo debe evaluar los esfuerzos de una historia completa o un error solucionado . Una historia con 6 tareas no se completa hasta que se completen esas 6 tareas.

Un flujo de trabajo propuesto fue este (pero con algunos problemas):

  1. Desarrollamos en una ' twig de sprint '. Todo lo que se hace en el sprint se registra en esta twig. Cuando se completan todas las tareas para una historia, la twig se fusiona con el tronco y se genera una construcción nocturna.
  2. Al final del sprint nos unimos al tronco.

Los problemas con esto son que para el paso 1 , cuando nos fusionamos al tronco también podríamos estar fusionando historias incompletas (y lo mismo para el paso 2 ).

Esto nos deja con este flujo de trabajo propuesto:

  1. Para cada historia, creamos una twig de historia / característica.
  2. Cuando se completa una historia, nos fusionamos desde el tronco ( recogiendo otras historias completas y correcciones de errores ), y luego nos fusionamos con el tronco . Trunk ahora contiene una nueva historia completa .
  3. Luego generamos una creación nocturna

Parece que podría resolver la mayoría de los problemas asociados con Historias incompletas. Pero, introduce la complejidad y la sobrecarga de múltiples twigs.

Nos interesaría saber lo que hace, y en particular si usted:

  • Desarrollar en el tronco
  • Desarrollar en una twig relacionada con sprint
  • Desarrollar en twigs de características / historias

Si utiliza uno de los enfoques de la twig , ¿qué gastos indirectos introduce y vale la pena?

Desarrollamos en trunk, pero nunca tenemos Stories incompletos al final de la iteración. No tenemos historias que no encajen en una iteración. Las historias más grandes se dividen en otras más pequeñas.