¿Los DVCS desalientan la integración continua?

Digamos que hay un equipo de diez desarrolladores ágiles. Todos los días, cada uno elige una tarea del tablero, comete varios cambios en su contra, hasta que (al final del día) hayan completado la tarea. Todos los desarrolladores se registran directamente en el enlace troncal (al estilo de Google, cada confirmación es un candidato de lanzamiento, utiliza funciones, etc.).

Si usaban un CVS centralizado como SVN, cada vez que uno de ellos se compromete, el servidor de compilación se integrará y probará sus cambios contra el trabajo de los otros nueve desarrolladores. El servidor de compilación estará funcionando prácticamente todo el día.

Pero si estaban usando un DCVS como git, el desarrollador puede esperar hasta que completen la tarea antes de enviar todos sus compromisos locales al repositorio central. Sus cambios no se integrarán hasta el final del día.

En este escenario, el equipo SVN se integra continuamente con mayor frecuencia y descubre problemas de integración mucho más rápido que el equipo git.

¿Significa esto que los DVCS son menos adecuados para equipos continuos que las herramientas centralizadas más antiguas? ¿Cómo se solucionan este problema de empuje diferido?

Descargo de responsabilidad: trabajo para Atlassian

DVCS no desalienta la integración continua siempre y cuando el desarrollador empuje remotamente de forma regular a su propia sucursal y el servidor CI esté configurado para que construya las sucursales activas conocidas.

Tradicionalmente hay dos problemas con DVCS y CI:

• Incertidumbre del estado de integración : a menos que el desarrollador se haya fusionado regularmente del maestro y ejecute la compilación, no sabe cuál es el estado de los cambios combinados. Si el desarrollador tiene que hacer esto manualmente, lo más probable es que no se haga con la frecuencia suficiente para resolver los problemas lo suficientemente temprano.
• Duplicación y deriva de la configuración de compilación : si la configuración de compilación debe copiarse de una compilación 'maestra' para crear una compilación de bifurcación, la configuración de la bifurcación puede quedar rápidamente sincronizada con la compilación de la que se copió.

En Bamboo, introdujimos la capacidad para que el servidor de compilación detecte nuevas sucursales a medida que las crean los desarrolladores y configura automáticamente las compilaciones para la sucursal en función de la configuración de compilación para el maestro (por lo que si cambia la configuración de compilación de maestros, también cambia la configuración de las sucursales para reflejar el cambio).

También tenemos una característica llamada Estrategias de combinación que se puede usar para actualizar la rama con cambios desde el maestro antes de que se ejecute la compilación de la rama o automáticamente empujar los cambios en una rama de compilación exitosa a la maestra, asegurando que los cambios entre las ramas se prueben juntos lo antes posible .

De todos modos, si está interesado en aprender más, vea mi publicación de blog "Hacer efectivas las ramas de características con integración continua"

Mi pequeño equipo se cambió a un DVCS hace un año o dos, y el resto de mi compañía hizo lo mismo hace un par de meses. En mi experiencia:

• Las personas que usan un VCS centralizado aún tienden a retrasar los compromisos cuando están haciendo un proyecto grande. Este no es un problema exclusivo de DVCSes. Tendrán conjuntos de cambios que esperarán varios días antes de realizar una confirmación. La gran diferencia es que si cometen un error en algún momento durante este tiempo, o si la computadora falla, se requiere mucho más esfuerzo para solucionarlo.
• Utilizamos un flujo de trabajo de confirmación en el que cada desarrollador trabaja en su propia rama con nombre, y solo la persona que revisó su código puede fusionar sus cambios en la cabeza. Esto reduce la probabilidad de que un compromiso cause problemas, por lo que las personas realmente prestan atención cuando el servidor de compilación genera un mensaje de error. También significa que otros desarrolladores pueden continuar trabajando en sus propias ramas hasta que se arregle la cabeza.
• En un DVCS, las personas tienden a pasar más tiempo programando antes de fusionar su código con la cabeza. Por lo tanto, tiende a introducir un pequeño retraso en la continuidad de la compilación. Pero la diferencia no es lo suficientemente significativa como para contrarrestar las ventajas del DVCS.

Recientemente observé en unos 19 proyectos que usaban Mercurial sobre SubVersion (yo era un geek de la subversión ): los desarrolladores comenzaron a ser realmente individualistas al trabajar en su propia rama e integrarse solo después de varios días o semanas. Esto causó serios problemas de integración y preocupaciones.

Otro problema que enfrentamos es con el servidor de integración continua. Se nos notificaron problemas (por ejemplo, una prueba fallida), solo cuando se realizó la sincronización de confirmaciones en el servidor.

Parece que Martin Fowler escribió sobre ello en su sitio.

Dicho esto, algunos de los proyectos que menciono se sincronizaron al menos una vez al día para reducir los problemas. Entonces, para responder a su pregunta, creo que DVCS puede desalentar la integración continua y aumentar el individualismo. Sin embargo, DVCS no es la causa directa.

El desarrollador todavía está a cargo independientemente del VCS que usan.

La idea en la que basa su razonamiento es muy inestable, en voz baja. Es cuestión de equipo / gestión / proceso que el desarrollador puede esperar hasta completar la tarea .

Hacerlo de una forma u otra, "esperar" o "apurarse", troncal compartida o rama aislada, se conoce como estrategia de ramificación , y si estudia la información disponible en línea , descubrirá que elegir una estrategia en particular básicamente no tiene nada que ver con VCS centralizado o distribuido.

Digamos, para VCS distribuidos como Mercurial, puede encontrar fácilmente una recomendación sólida para fusiones frecuentes :

Primero, fusionarse a menudo! Esto hace que la fusión sea más fácil para todos y descubra los conflictos (que a menudo se basan en decisiones de diseño incompatibles) antes ...

Al estudiar las recomendaciones anteriores, uno puede descubrir fácilmente que estas apelan a consideraciones que no tienen nada que ver con la distribución de Mercurial.

Ahora, veamos la situación al lado de VSC centralizado, Subversion. Al estudiar la información en línea, uno puede encontrar entre las principales estrategias populares llamadas troncal estable y troncal inestable , cada una de las cuales tiene un impacto opuesto en la frecuencia de las fusiones. Verá, las personas eligen una u otra forma de hacer las cosas sin siquiera prestar atención a que VCS esté centralizado.

• ^{He visto fusiones severamente retrasadas (incluso alentadas por la administración poco convincente) con VCS centralizado, así como frecuentes fusiones realizadas con DVCS cuando el equipo / la administración simplemente pensaban que era la forma correcta. He visto que a nadie le importa si VCS está distribuido o centralizado para decidir de una forma u otra.}

Dado anteriormente, parece la respuesta correcta a ¿Los DVCS desalientan la integración continua? sería Mu .

La distribución o no de VCS no tiene un impacto sustancial en eso.

Mi experiencia es exactamente lo contrario , los equipos que usan svn no presionarían durante días, porque el código en el que estaban trabajando haría que la troncal no se compilara para todos los demás sin perder tiempo en la fusión manual. Luego, cerca del final del sprint, todos se comprometerían, se produciría una locura de fusión, las cosas se sobrescribirían y se perderían y tendrían que recuperarse. El sistema de CI se pondría ROJO y seguiría señalando con el dedo.

Nunca tuve este problema con Git / Gitorious.

Git le permite tirar y fusionar otros cambios pueblos a su conveniencia, no porque alguien más marcada algo y que desea comprobar en pero tienes 20 minutos de la combinación manual a hacer.

Git también le permite obtener las confirmaciones de todos los demás, fusionar su código y luego enviar una versión funcional a todos los demás para que no tengan que adivinar qué deberían fusionar en función de lo que cambió.

Tener algo como Gitorious como mediador para las revisiones de código a través de solicitudes de fusión hace que administrar muchas sucursales y muchos contribuyentes sea muy sencillo.

Configurar Jenkins / Hudson para rastrear todas las ramas activas en un repositorio de Git también es muy fácil. Obtuvimos más tracción con CI y comentarios más frecuentes sobre el estado de los repositorios cuando nos mudamos a Git desde SVN.

Los servidores de compilación son baratos. Simplemente haga que su servidor CI recoja todas las ramas que conoce.

Jenkins tiene soporte para comprobar múltiples repositorios Git y conseguir la 'última' de cualquiera de los de un solo trabajo. Estoy seguro de que hay soluciones similares con otras herramientas.

Esta vieja pregunta acaba de ser marcada como un duplicado de una nueva, y dado que muchas de las respuestas hacen referencia a algunas ideas obsoletas, pensé que publicaría una actualizada.

Una cosa que aparentemente no era muy común hace cinco años era ejecutar pruebas de CI en ramas de solicitud de extracción antes de fusionarlas en maestra. Creo que esto refleja una actitud cambiante que, aunque fusionarse con frecuencia es deseable, compartir cada cambio con todos , tan pronto como lo haga , no es óptimo.

DVCS ha generado un modo más jerárquico de integrar sus confirmaciones. Por ejemplo, a menudo trabajo en tareas muy de cerca con el desarrollador que se sienta a mi lado. Nos separaremos de las ramas del otro varias veces al día. Hoy, colaboramos con otro desarrollador a través de cambios enviados a una solicitud de extracción cada pocas horas.

Estábamos haciendo grandes cambios en los scripts de compilación. Jenkins fusiona localmente cada rama de relaciones públicas con master y ejecuta pruebas, por lo que obtuvimos comentarios automatizados de esa manera, sin molestar a ningún otro desarrollador que necesitara una compilación limpia. Probablemente pasará otro día más o menos antes de que PR esté listo para fusionarse para dominar y compartir fuera de nuestro grupo de tres desarrolladores.

Sin embargo, si alguien no puede esperar a que nuestros cambios se fusionen para dominar, porque su cambio depende de los nuestros, puede fusionar nuestra rama de desarrollo localmente y continuar con su trabajo. Esto es lo que muchas personas que están acostumbradas a CVCS extrañan. Con CVCS, la única forma de compartir sus cambios es fusionarlos en el repositorio central, y es por eso que la fusión a menudo es más crítica. Con DVCS, tiene otras opciones.

Yo diría que el DVCS es más propicio para la integración continua. Las fusiones no son tan irritantes con ellos. Sin embargo, requiere más disciplina. Debe seguir una confirmación local con un tirón desde la base para fusionarse y luego presionar cuando se complete su tarea (antes de pasar a la siguiente).

Cuando mi equipo cambió a Git, expusimos explícitamente nuestro proceso de tal manera que un impulso debía tratarse exactamente como un commit en el VCS anterior, y los commits locales se podían hacer con la frecuencia o la frecuencia que cada individuo elegía. Con eso, no hay diferencia en el sistema de CI si estamos usando un DVCS o un VCS centralizado.

La respuesta es ambas, si y no.

La diferencia aquí es entre comprometerse directamente con el repositorio central visto en CI y empujar sus cambios al repositorio central visualizado en CI. El 'problema' que puede encontrar es que los usuarios de DVCS en realidad no pueden realizar ese impulso regularmente.

Yo diría que esta es una característica de diseño inherente de un DVCS, no está diseñada para enviar sus cambios al servidor central todo el tiempo; si lo fuera, también podría usar un CVCS. Entonces, la respuesta es imponer un mejor flujo de trabajo entre sus desarrolladores. Diles que empujen los cambios todas las noches. Simples!

(y si los usuarios de SVN no se comprometen todas las noches, dígales que es exactamente el mismo problema).

Git no impide la integración continua. Su flujo de trabajo basado en troncales es.

Eso puede sonar contradictorio, pero: si los desarrolladores trabajan en ramas de características, se les puede animar a que se integren con frecuencia en sus propias máquinas (y deben hacerlo antes de enviar su característica para fusionarla). Por el contrario, un flujo de trabajo basado en troncales favorece compromisos más grandes y, por lo tanto, una integración menos frecuente.

Sostengo que un flujo de trabajo basado en troncales al estilo de Google es contraproducente con un VCS como Git, donde la fusión es fácil. Esto es lo que recomendaría en su lugar:

• Descomponga las características lo suficientemente pequeñas como para que ninguna tarde más de un día o dos en desarrollarse.
• Cada característica se desarrolla en una rama privada.
• El desarrollador se integra con frecuencia en la rama privada ( git fetch origin; git merge master). Normalmente hago esto muchas veces al día cuando trabajo de esta manera.
• Cuando la rama promotor presenta para la fusión y la revisión, el servidor hace un CI de construcción automatizado. Combinar sólo ocurre cuando este pasa.

Así que ahí lo tienen: pequeñas las confirmaciones, la integración frecuente, y una historia de rastrear lo que compromete a la que pertenecía a función. Ramas, utilizados correctamente, son la clave de todo lo que vale la pena sobre Git, evitando así que es un gran error.

Existen soluciones técnicas impresionantes como @jdunay mencionado, pero para nosotros es un problema de la gente - de la misma manera que el fomento de un entorno donde la gente se comprometen a svn menudo es una cuestión de personas.

Lo que ha funcionado para nosotros es: (sustituir 'maestro' con la rama dev actualmente activo)

1. Fusiones / rebases frecuentes del maestro
2. Empujes lo suficientemente frecuentes para dominar

3. Conciencia de las cosas que causan la fusión del infierno, como ciertas refactorizaciones, y mitigar esto mediante la comunicación. Por ejemplo:

   • Asegúrese de que todos empujen antes del almuerzo
   • Realizar y refactorizar durante el almuerzo.
   • Asegúrese de que todos tiren después del almuerzo