¿Los DVCS como Git son inapropiados para los equipos que utilizan la integración continua?

Question

Los procesos de desarrollo de mi equipo se basan en integración continua . Las únicas ramas que creamos son ramas de mantenimiento cuando lanzamos, pero de lo contrario se espera que los desarrolladores se comprometan regularmente (a diario, si no con mayor frecuencia) a troncal, para que el trabajo de todos esté siempre integrado, probado continuamente y todas esas cosas buenas.

Mi comprensión de DVCS es que es excelente para la ramificación. Trabajé hace algunos años en un equipo donde esto habría sido muy útil, ya que cada parte del desarrollo se realizó en una rama y solo se fusionó cuando se completó y se probó. Pero esta era una filosofía diferente de la integración continua.

Pero me parece que para un equipo que utiliza la integración continua, las características geniales de las herramientas DVCS como Git no sería particularmente relevante e incluso podría obstaculizar el proceso de integración continua si la fusión de cambios requiere pasos adicionales que pueden olvidarse.

Estoy seguro de que hay otros beneficios de un DVCS (por ejemplo, la confirmación es muy rápida porque es local, presumiblemente la fusión con la rama principal podría ocurrir en segundo plano mientras el desarrollador continúa trabajando).

Pero para esta pregunta, estoy interesado en cómo los equipos que usan DVCS y la integración continua concilian las dos filosofías aparentemente conflictivas. Estoy interesado principalmente en escuchar a personas que realmente están haciendo esto.

Answer 1

En realidad, DVCS hizo la integración continua mucho más fácil.

Con VCS central, cada desarrollador tiene los derechos para comprometerse directamente en el tronco y, por lo tanto, puede cometer código defectuoso. CI lo detectará después del hecho. Por lo tanto, es posible tener un tronco roto incluso con CI.

Por otro lado, las operaciones básicas en el mundo DVCS son la ramificación y la fusión. Debido a que la fusión es explícita y un proceso separado frente a la confirmación en la troncal, siempre se puede verificar el resultado de una fusión antes de que aterrice en la troncal. No tengo experiencia con Git, pero los desarrolladores de Bazaar VCS han utilizado esta técnica con éxito durante al menos 3,5 años con la ayuda de la herramienta PQM.

Básicamente, el flujo de trabajo de PQM tiene el siguiente aspecto: el desarrollador publica su sucursal para que pueda fusionarse, luego envía un correo electrónico especial al bot de PQM con instrucciones de fusión. Cuando PQM recibe una solicitud de fusión, crea una rama de integración separada (copia del tronco), luego combina la rama del desarrollador y ejecuta pruebas en el código resultante. Si se pasan todas las pruebas, la rama de integración se transfiere a la troncal; de lo contrario, el desarrollador recibirá un correo electrónico con el registro de las pruebas fallidas.

La ejecución de todas las pruebas para el proyecto Bazaar lleva tiempo, pero las pruebas se ejecutan bajo demanda en un servidor separado. Los desarrolladores no serán bloqueados por fusiones y pueden continuar trabajando en otras tareas.

Como resultado del flujo de trabajo de fusión basado en PQM, la troncal bzr nunca se rompe (al menos mientras haya suficientes pruebas de aceptación y regresión).

Answer 2

Dado que todos los DVCS se pueden usar con un flujo de trabajo que usa un repositorio centralizado, no hay problema. La política dicta que el desarrollador debe enviar sus cambios al repositorio central exactamente de la misma manera que la política dicta los compromisos con un VCS no distribuido. Las herramientas adicionales que permiten al desarrollador editar conjuntos de parches no son un obstáculo de ninguna manera, y de hecho hacen que sea mucho más fácil generar una base de código que se pueda mantener.

Answer 3

El uso de un DVCS como Git no le impide comprometerse regularmente con un repositorio central. Sin embargo, significa que puede realizar confirmaciones intermedias localmente y solo enviar los cambios al repositorio central una vez que haya terminado.

De esta manera, usted tiene los beneficios del control de código fuente incluso cuando está implementando una característica a mitad de camino, sin romper la compilación para los otros desarrolladores.

Answer 4

Las herramientas de integración continua como Hudson tienen soporte para DVCS, por lo que sospecho que es posible conciliar la integración continua con el control de versiones distribuido.

Primero, creo que con DVCS usar flujos de trabajo como CI de flujo de trabajo de rama temática podría ser menos necesario. En segundo lugar, puede configurar un repositorio de integración continua (único, central) al que empuje cuando esté listo, y los ganchos hacen CI.

---

Agregado 07-08-2009:

Ver, por ejemplo, Publicación de integración continua de limpieza de primavera en el blog de GitHub .

Answer 5

Dos ideas para las que he encontrado ayuda explican esto:

• DVCS separa los commits de las fusiones.
• CI se ejecuta contra un repositorio que elija.

Entonces, el meollo del asunto es cómo se hacen las fusiones en los repositorios en los que desea ejecutar una herramienta de CI. Puede elegir tener un solo repositorio cuando comience.