¿Los DVCS desalientan la integración continua?

34

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?

Richard Dingwall
fuente
15
¿Las personas se comprometerán al menos una vez antes de completar la tarea al usar SVN? ¿Y las personas solo presionarán una vez al día cuando usen un DVCS? Su razonamiento asume que ninguno de los dos es cierto, pero mi impresión indica lo contrario.
3
Muy buena pregunta
Michael Brown
1
@delnan: suponga que ambos equipos se comprometen varias veces al día, pero los muchachos de git solo unen esos compromisos cuando se completa la tarea.
Richard Dingwall
2
Creo que estás mirando el extremo equivocado de la tubería, tienes problemas, no si no presionas hasta completarlo, sino si no lo haces regularmente durante el desarrollo
jk.
2
He visto lo contrario: los desarrolladores que usan un sistema de control de fuente centralizado como TFS se comprometen raramente, porque su código afecta a todos cuando lo hacen. Terminan guardando temporalmente su trabajo en estanterías de monstruos, y cuando terminan, todo va en una confirmación de monstruos.
Kyralessa

Respuestas:

26

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"

jdumay
fuente
14

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.
StriplingWarrior
fuente
¿El servidor de compilación construye todas las ramas con nombre para que cada committer tenga su propio trabajo de servidor de compilación?
¿El revisor de código no se convierte en un serio cuello de botella en este escenario?
Andres F.
@ ThorbjørnRavnAndersen: No, el servidor de compilación solo construye la rama "principal" o "predeterminada", y las ramas de lanzamiento. Por lo tanto, cada usuario puede comprometerse con su propia rama con nombre sin temor a romper la construcción. Podríamos configurar un servidor de compilación para construir las sucursales de todos, pero en algunos casos quiero comprometer algo de trabajo que he hecho, sabiendo muy bien que pone mi propia sucursal en un estado inutilizable. Me aseguraré de que mi rama sea estable antes de hacer una revisión de código y fusionarme. Solo me importa que las ramas principales que todos los demás usan sean estables.
StriplingWarrior
@AndresF .: No, no se ha convertido en un cuello de botella serio para nosotros. Por un lado, tenemos varias personas que pueden hacer revisiones de código, por lo que cada desarrollador generalmente puede encontrar al menos un revisor que esté disponible para una revisión en un momento dado. Además, parte de la belleza de un DVCS es que incluso si no puede fusionarse de inmediato, puede comenzar a trabajar en otra cosa, y otros desarrolladores pueden fusionar sus cambios en sus ramas si dependen de sus cambios para su trabajo. Una vez que se revisa su código, hay un nodo de conjunto de cambios específico en el que el revisor puede fusionarse.
StriplingWarrior
13

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.

Comunidad
fuente
¿Dichos proyectos enfatizaron un objetivo común o los desarrolladores tuvieron que trabajar en objetivos específicos y desconectados?
No podemos generalizar en 19 proyectos. Pero cuando enfrentamos problemas de integración, eso también se debe a que algunos principios como la separación de preocupaciones no fueron respetados. Lo que digo es que sí, DVCS parece alentar el individualismo y reducir los beneficios de la integración continua, pero, si los desarrolladores están bien entrenados, es posible reducir o eliminar el problema.
En ese caso, le sugiero que también realice entregas continuas, o al menos entregas frecuentes de clientes, por lo que el plazo para cuando la fusión DEBE suceder es mucho más corto. ¿Hiciste eso en estos proyectos?
Por supuesto, usamos Scrum
1
Yo estaba buscando su definición de la entrega continua (todavía no puede encontrar algo decente, apreciaré si usted me podría dar algunas referencias), y encontré esto: continuousdelivery.com/2011/07/...
10

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.

mosquito
fuente
1
+1 Estoy de acuerdo con usted en que la administración es la clave para resolver el problema. Sin embargo, debemos admitir que hay algo en DVCS que desalienta la integración continua. De hecho, una de las características clave de DCVS fomenta ese comportamiento.
1
@ Pierre303 tal vez, de alguna manera yo también me siento así, pero eso es básicamente una teoría. Mientras escribía, he visto al equipo integrarse como loco con DVCS y, por otro lado, el proyecto más "aislacionista" en el que he trabajado (y eso fue una pesadilla) fue con VCS centralizado. Tanto por los sentimientos, tanto por la teoría ...
mosquito
Admito que es solo una observación empírica, pero en un gran número de proyectos, y probablemente hay un gran sesgo de "habilidad" involucrado.
10

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.


fuente
¿por qué se comprometan directamente al tronco? Creo que esto era su problema.
gbjbaanb
1
@gbjbaanb porque esa es la forma tradicional de trabajar CVS idiomática, ya que este es el lenguaje tradicional de cesión temporal centralizado. SVN usuarios suelen ser antiguos usuarios de CVS, y ramas y la mezcla en SVN es sólo marginalmente mejor que en el CVS; que estaba más allá dolorosa / casi imposible de conseguir la correcta. Este es el caso del flujo de trabajo del 99% en el 99% de todas las tiendas de SVN a causa de las herramientas y pensamiento de grupo.
@JarrodRoberson: sin sentido. Mis viejos usuarios de SVN eran refugiados de VSS :) La fusión en SVN no es tan malo como usted piensa. En este caso, se queja de que sus usuarios romperían la compilación al ingresar el código roto directamente en la troncal, y luego tener que fusionar, francamente, tener que fusionar su código con el de su colega no es una opción si todos están trabajando directamente en La misma rama.
gbjbaanb
4

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.

ptyx
fuente
¿Y qué sucede si quiere cometer algo que se rompe headpero que ayuda a un colega o es necesario para que un colega pueda ayudarlo? Puede crear un diff y enviarlo por correo electrónico a su colega, pero de alguna manera eso no se siente bien.
Arjan
1
Equipo / rama de características? ¿O extracción directa del repositorio de su colega? Si más de una persona está trabajando en algo que rompería la cabeza pero aún requiere una confirmación de línea de tiempo / etapa múltiple, de todos modos merece su rama de función / trabajo. Fusionar a la cabeza cuando esté listo.
ptyx
Una rama de equipo de la rama de características no funcionará si su herramienta de CI recoge todas las ramas que conoce. Y si su herramienta de CI también procesa múltiples repositorios, aún no desea incluir repositorios de desarrollador, simplemente porque es posible que no se hayan probado completamente.
Arjan
1
El servidor CI no sabrá automáticamente de una sucursal privada hasta que se le informe al respecto. Hasta las personas que eligen si quieren sus sucursales en CI o no. (No hay una solución milagrosa)
ptyx
Por lo tanto, CI no debe recoger todas las ramas que conoce, sino solo aquellas que desee en CI. Para mí eso es una diferencia. Aún así, creo que entiendo lo que estás tratando de decir, así que +1
Arjan
4

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.

Karl Bielefeldt
fuente
3

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).

Michael Brown
fuente
2

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.

Dan Lyons
fuente
1

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).

gbjbaanb
fuente
0

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.

Marnen Laibow-Koser
fuente
-1

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
orip
fuente