practices - ¿Los DVCS como Git son inapropiados para los equipos que usan integración continua?
git tag commands (5)
Como todos los DVCS se pueden usar con un flujo de trabajo que utiliza un repositorio centralizado, no hay ningún problema. La política establece que el desarrollador debe enviar sus cambios al repositorio 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 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.
Los procesos de desarrollo de mi equipo se basan en la 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 (diariamente si no más a menudo) con el tronco, para que el trabajo de todos esté siempre integrado, continuamente probado y todo lo 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 rama, y solo se combinó 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 usa la integración continua, las características maravillosas de las herramientas DVCS como Git no serían particularmente relevantes, e incluso podrían obstaculizar el proceso 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 rama principal podría ocurrir en el fondo mientras el desarrollador continúa trabajando).
Pero para esta pregunta, me interesa cómo los equipos que usan DVCS y la integración continua reconcilian las dos filosofías aparentemente conflictivas. Estoy interesado principalmente en escuchar de personas que realmente están haciendo esto.
Dos ideas que he encontrado ayudan a explicar esto:
- DVCS separa las confirmaciones de las fusiones.
- CI se ejecuta contra un repositorio que elija.
Entonces, el meollo del asunto es cómo se realizan las fusiones en los repositorios en los que se quiere ejecutar una herramienta de CI. Puedes elegir tener solo un repositorio cuando comiences.
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 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 proceso 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 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, y 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 de troncal), luego fusiona la rama del desarrollador y ejecuta pruebas en el código resultante. Si se superan todas las pruebas, la rama de integración se envía al enlace troncal; de lo contrario, el desarrollador recibirá un correo electrónico con el registro de las pruebas fallidas.
Ejecutar todas las pruebas para el proyecto Bazar 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, el troncal bzr nunca se rompe (al menos mientras haya suficientes pruebas de aceptación y regresión).
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 versión distribuida.
En primer lugar, creo que con DVCS utilizando flujos de trabajo como el flujo de trabajo de la rama de tema, CI puede ser menos necesario. En segundo lugar, puede configurar el repositorio de integración continua (ú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 primavera de integración en el blog de GitHub.
Usar un DVCS como Git no le impide comprometerse regularmente con un repositorio 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, tiene 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.