¿Control de versión ágil?

Question

Estoy tratando de encontrar un buen método para administrar los cambios de código en un proyecto grande con varios equipos. Usamos subversión en este momento, pero quiero más flexibilidad para crear un nuevo lanzamiento de lo que parece que puedo obtener con subversión.

Aquí es más o menos lo quieren:

• para cada desarrollador para crear parches fácilmente identificables para el proyecto. Cada parche brinda una historia completa del usuario (una función o solución liberable). Puede abarcar muchos cambios en muchos archivos.
• desarrolladores son capaces de aplicar y retirar fácilmente sus propios y otros parches para facilitar las pruebas
gestor de
• liberación selecciona los parches que se utilizarán en la próxima versión en una nueva rama
• rama se prueba, correcciones se fusionaron en, y finalmente fusionados en vivo
• los equipos pueden volver a colocar estos cambios en sus sandboxes.

Estoy buscando stacked git como una forma de lograr esto, pero ¿qué otras herramientas o técnicas pueden ofrecer este tipo de flujo de trabajo?

Answer 1

Estoy tratando de encontrar un buen método para administrar los cambios de código en un proyecto grande con varios equipos.

Recomiendo leer el artículo Version Control for Multiple Agile Teams de Henrik Kniberg en InfoQ.

En resumen:

• El tronco contiene historias HECHO HECHO, tiene una política liberable (puede ser liberado en cualquier momento).
• El desarrollo se realiza en ramas de trabajo (una por equipo), tienen una política más flexible (unidad probada).
• cuando se HACE una historia, se empuja desde la rama de trabajo al tronco.
• Merge from trunk to work branches se realizan todos los días.

Aquí es una ilustración de toda una carrera de velocidad:

Ésta es una versión muy simplificada de papel de Henrik, pero eso es el espíritu. Es totalmente compatible con nuestro proceso (Scrum) y funciona muy bien para nosotros.

PD: Por cierto, realmente no entiendo por qué los desarrolladores trabajarían durante una iteración en algo que los administradores de versiones no elegirían para el lanzamiento.

Answer 2

Me suena como que necesita una instalación de integración continua como el control de crucero, Hudson, crucero, equipo de la ciudad, etc.

Answer 3

Si sus historias son realmente aislado y muy aditivo (muy poco cambio en las líneas de código existentes) , el enfoque podría funcionar Sin embargo, a medida que el trabajo se entrelaza más y más, las fusiones se volverán cada vez más difíciles.

Los entornos de CI, como lo sugiere duffymo, ayudarán, pero esas herramientas de mi experiencia no tienen muchas (o ninguna) características para construir muchas versiones del proyecto ni ser inteligentes sobre la mezcla/fusión de ramas.

Podría ser mejor adoptar un enfoque más jerárquico. Cada grupo debe tener su propia IC y luego pasar a un sistema de versión maestro/sistema de CI cuando sea apropiado (¿fin del sprint de cada grupo?). Esto minimizaría las interacciones dolorosas para el grupo, pero permitiría que el proyecto en conjunto avance continuamente. Si tiene muchos grupos, agregue algunos niveles adicionales de integración.

Tenga en cuenta que, en este enfoque, las pruebas unitarias pueden permanecer en el nivel grupal, pero deberá encontrar formas de escribir pruebas de integración y del sistema que puedan funcionar en las compilaciones de alto nivel.

En el lado de toolage, cualquiera de los conjuntos de herramientas de CI debería funcionar. Para el control de versiones, Git y Mercurial admiten este tipo de enfoque (otros también pueden).

No es exactamente lo que está pidiendo, pero no creo que haya muchas herramientas que abordan el tipo de enfoque que desea tomar. Además, creo que un número razonable de historias provoca un nivel de refactorización de las existentes que dificultará la mezcla y los cambios de correspondencia.

Answer 4

Esto es una ilusión a menos que, como ya se dijo, cada característica no se superpone en absoluto. Esa es una excepción y no la regla.

Una mejor manera de hacerlo es involucrar realmente al equipo (s) y tener una idea de cuándo algunas características pueden estar cerca de completarse. Haga que estos equipos de rama fusionen sus ramas a medida que se desarrollan. Fusionarlos en la rama de desarrollo y luego en el master luego de su lanzamiento será muy fácil.

Hay algunos puntos a añadir:

Rebase cuando sea posible, sobre todo si una característica no se ha trabajado durante un tiempo. Rebasing solidificará las resoluciones de conflictos en una historia lineal. Las fusiones o rebases posteriores no tendrán que volver a tomar estas decisiones, en cuyo momento la recolección puede no ser tan precisa.

Utilice la opción --no-ff (no avance rápido) al fusionar una rama en otra. Esto garantiza que si la segunda rama no tiene compromisos para fusionarse, se agrega una confirmación vacía que señala las dos ramas que se fusionan. Si esto no se hace, puede perder un punto de ramificación. Esta puede ser información importante.