¿Los DVCS como Git son inapropiados para los equipos que usan continuous integration?

Los processs de desarrollo de mi equipo se basan en la continuous integration . Las únicas twigs que creamos son twigs de mantenimiento cuando lanzamos, pero de lo contrario se espera que los desarrolladores se comprometan regularmente (diariamente si no más a menudo) con el tronco, para que el trabajo de todos esté siempre integrado, continuamente probado y todo eso bueno.

Mi comprensión de DVCS es que es ideal para la bifurcación. Trabajé hace algunos años en un equipo en el que esto hubiera sido muy útil, ya que cada parte del desarrollo se realizó en una twig, y ​​solo se combinó cuando se completó y se probó. Pero esta era una filosofía diferente de la continuous integration.

Pero me parece que para un equipo que usa la continuous integration, las características maravillosas de las herramientas DVCS como Git no serían particularmente relevantes, e incluso podrían obstaculizar el process de integración continuo si la fusión de cambios requiere pasos adicionales que pueden olvidarse.

Estoy seguro de que hay otros beneficios de un DVCS (por ejemplo, el compromiso es muy rápido porque es local, supuestamente la fusión con la twig principal podría ocurrir en el background mientras el desarrollador continúa trabajando).

Pero para esta pregunta, me interesa cómo los equipos que usan DVCS y la continuous integration reconcilian las dos filosofías aparentemente conflictivas. Estoy interesado principalmente en escuchar de personas que realmente están haciendo esto.

En realidad, DVCS hizo la continuous integration mucho más fácil.

Con VCS central, cada desarrollador tiene los derechos para comprometerse directamente en el enlace troncal y, por lo tanto, puede cometer errores de código. 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 bifurcación y la fusión. Debido a que la fusión es explícita y un process separado vs. compromiso con el enlace troncal, siempre se puede verificar el resultado de una fusión antes de que aterrice en el enlace troncal. No tengo experiencia con Git, pero los desarrolladores de Bazaar VCS han usado esta técnica con éxito durante al less 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, y luego envía un correo electrónico especial al bot de PQM con instrucciones de fusión. Cuando PQM recibe una request de fusión, crea una twig de integración separada (copy de troncal), luego fusiona la twig del desarrollador y ejecuta testings en el código resultante. Si se superan todas las testings, la twig de integración se envía al enlace troncal; de lo contrario, el desarrollador recibirá un correo electrónico con el logging de las testings fallidas.

Ejecutar todas las testings para el proyecto Bazar lleva time, pero las testings se ejecutan bajo demanda en un server 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, el troncal bzr nunca se rompe (al less mientras haya suficientes testings de aceptación y regresión).

Como todos los DVCS se pueden usar con un flujo de trabajo que utiliza un repository centralizado, no hay ningún problema. La política establece que el desarrollador debe enviar sus cambios al repository central exactamente de la misma manera que las políticas dictan que se compromete con un VCS no distribuido. Las herramientas adicionales que permiten al desarrollador editar sets 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.

Usar un DVCS como Git no le impide comprometerse regularmente con un repository central. Sin embargo, sí significa que puede realizar confirmaciones intermedias localmente y solo enviar los cambios al depósito central una vez que haya finalizado.

De esta forma tendrá los beneficios del control de código fuente, incluso cuando esté implementando la mitad de una característica, sin romper la construcción para los otros desarrolladores.

Las herramientas de continuous integration como Hudson tienen soporte para DVCS, por lo que sospecho que es posible conciliar la continuous integration con el control de versión distribuida.

En primer lugar, creo que con DVCS utilizando flujos de trabajo como el flujo de trabajo de la twig de tema, CI puede ser less necesario. En segundo lugar, puede configurar el repository de continuous integration (único, central) al que presiona cuando está listo, y los ganchos hacen CI.


Agregado 07-08-2009:

Consulte, por ejemplo, la publicación Limpieza continua de spring de integración en el blog de GitHub.

Dos ideas que he encontrado ayudan a explicar esto:

  • DVCS separa las confirmaciones de las fusiones.
  • CI se ejecuta contra un repository que elija.

Entonces, el meollo del asunto es cómo se realizan las fusiones en los repositorys en los que se quiere ejecutar una herramienta de CI. Puedes elegir tener solo un repository cuando comiences.