Aproximaciones de control de versiones en Scrum

Recientemente, con mis compañeros de trabajo, estuvimos discutiendo cómo organizar el control de versiones en un proyecto de Scrum. Más específicamente, ¿los criterios para la creación de sucursales (por desarrollador, por tarea, por historia, por Sprint?) Y los methods de integración.

Mi opinión es que una forma útil de organizarlo es crear una twig para cada User Story, para que pueda integrar cada Story en el trunk liberable una vez que se complete y también permite que siempre tenga una "versión entregable" de la aplicación en cualquier momento.

Por lo tanto, si una historia no se puede completar, puede omitirse y no comprometer el lanzamiento del sprint. (Que considerando una herramienta centralizada, si se usa una distribuida, las consideraciones serían diferentes)

Me gustaría conocer sus propios enfoques, qué tipo de herramientas prefiere y los pros y los contras que ha visto con la experiencia y las lecciones aprendidas.

Mantenga el protocolo de bifurcación ligero. En Scrum, si alguien quiere ramificar el código para trabajar en una característica específica, déjalos. Nadie debería temer ramificarse. Este es uno de los beneficios de DVCS: las personas se ramifican cuando lo desean y no están sesgadas por las normas o los estándares del equipo.

Por mi dinero, es caso por caso, y si comienzas a ver patrones en tus processs de desarrollo, formalízalos para que todos estén en sintonía.

Solo asegúrese de que cada desarrollador entienda que es su responsabilidad integrar y fusionar sus cambios. Eso debería establecer la barra alnetworkingedor del lugar correcto para asegurar que las personas hagan la llamada correcta sobre cuándo ramificar el código.

Una twig por cada historia de usuario me suena bastante excesiva. Mantenemos una única base de código (troncal) y trabajamos en esto. El único momento en el que normalmente nos ramificaría es solucionar un problema de producción actual que no podía esperar hasta un lanzamiento regular.

Es un tema muy interesante en realidad.

Siempre aplicamos la creación de twig por tarea; de hecho, cada tarea (no una historia, sino las tareas reales descompuestas después de la reunión de planificación de melé) tendrá al less una twig asociada.

Puedes ver cómo se ve en el siguiente diagtwig: texto alternativo

Esto hace que sea muy fácil alentar las evaluaciones por pares, ya que el equipo puede verificar qué se modificó en una tarea (sucursal), incluso cuando los desarrolladores decidieron realizar muchos compromisos intermedios (¡lo cual es una muy buena práctica!)

Hay una serie de enlaces a continuación que pueden ser útiles:

  1. Tarea por twig detallada
  2. ¡Ve Agile en 4 pasos!
  3. Y un screencast sobre esto aquí .

Cada vez que tenemos una historia o un set de historias que amenaza con dejar la twig principal en desorder durante varios días o involucra a 'muchos' desarrolladores, creamos una twig para eso (no es muy común, tratamos de tareas para evitar esto, pero sucede) como una especie de mitigación de riesgos. Queremos asegurarnos de que la twig maestra siempre esté list para ser liberada al final de cada sprint, incluso si potencialmente significa que quizás no hayamos aumentado el valor de la twig principal después del sprint.

La twig de historia / function / tarea se sincroniza con la twig principal muy a menudo, y el objective es que la twig se fusione siempre antes del final del sprint.

Por supuesto, todos usamos ' git ', así que en efecto siempre tenemos una sucursal local en la que trabajamos, y nos hemos vuelto bastante buenos sincronizando con master lo suficiente como para evitar integraciones de big-bang y rara vez para no dejarnos inútiles. / código no utilizado en la twig principal.

Aparte de eso, hacemos ' branch-by-purpose ' (PDF). También escribí un poco más sobre cómo hacemos git aquí .

Utilizaría una twig por lanzamiento y usaría Integración continua para evitar que una historia de usuario dañe a los demás.

El único cambio que debe hacer en su sistema de control de versiones de origen es integrarlo con el sistema de continuous integration (como TeamCity o CruiseControl.NET ).

Sí, sé que realmente no estoy respondiendo tu pregunta, pero realmente lo digo en serio. En el proyecto de software ágil, desea poder lanzar el producto a los clientes (o poder hacerlo) con la mayor frecuencia posible. Es por eso que necesita saber que lo que está en su sistema fuente está funcionando o si no funciona, por qué no está funcionando.

No veo cómo una ramificación por característica puede hacerte más ágil o delgada. El costo de la administración de la sucursal es demasiado alto. Yo diría que si crees que necesitas una sucursal por característica, tus historias son demasiado grandes. Una historia debe completarse en el próximo scrum y, si no, seguramente en la próxima. Entonces, si una twig solo existe por 1 o 2 días, no veo cómo puede ser útil o si se paga su costo. Para muchas personas es una rutina trabajar en una historia, por lo que a veces utilizo una twig de desarrollo para que los desarrolladores trabajen, de modo que puedan fusionar código Muchas veces al día mientras trabajan en la misma historia sin que se deployment el código para probar (twig principal) . Lo ideal sería tener tan pocas historias en progreso y completarlas tan rápido que solo necesitarías la twig Principal y no otras.