Integración continua con control de código fuente distribuido

Question

Creo que entiendo mal algo pero no puedo encontrar exactamente qué. Busqué en Google, pero no entendí la idea. Hay dos técnicas populares: integración continua y control de código fuente distribuido. La gente de alguna manera los combina, pero no entiendo cómo.

AFAIK, integración continua significa comprometerse con el repositorio central (push) tan pronto como haya probado su código localmente. Al mismo tiempo, los sistemas distribuidos son muy apreciados, entre otras cosas, porque usted puede comprometerse, comprometerse y comprometerse localmente, jugar con el código e impulsarlo a los demás solo cuando esté seguro y satisfecho con él. Por lo tanto, aunque no fuerza, sin embargo, alienta a no darse prisa con empuje. Me parece que el clásico para empujar CI cada varias horas no tendrá lugar.

Entonces, ¿cómo y cuándo unen estas dos cosas? ¿O estoy equivocado en lo que dije?

EDITAR

leí las tres primeras respuestas. Gracias por la respuesta. Todavía estoy confundido, pero ahora puedo formular la pregunta más precisa.

En sistemas distribuidos no hay tanto deseo de confirmaciones frecuentes, luego en centralizado. Entonces, ¿hay alguna guía sobre la frecuencia de publicación en sistemas distribuidos para cumplir con CI? ¿Sigue siendo varias veces al día o hay otra versión de esta regla?

Answer 1

El control de fuente distribuida y la integración continua no son conceptos mutuamente excluyentes. De hecho, juegan muy bien juntos.

Aunque los DVCS están distribuidos por naturaleza, todavía tendrá un repositorio central que representa el "tronco" tradicional que se encuentra en los sistemas de versión centralizada. No debe cambiar su modelo de desarrollo en términos de cuándo y qué cambios "publica" en su repositorio central. Debido a que DVCS no lo obliga a impulsar sus cambios, necesita ser muy disciplinado en ese sentido.

Por otro lado, DVCS permite a los desarrolladores realizar confirmaciones incrementales más pequeñas en sus sucursales privadas. No solo los cambios son más fáciles de seguir de esta forma, sino que también son más fáciles de combinar al final. Tener confirmaciones locales es especialmente útil al agregar una característica o realizar cambios experimentales. O cuando necesita interrumpir su trabajo en la característica A para corregir el error muy importante B.

El desarrollador individual decide qué se empujó/publicó cuando. Como siempre, con el poder adicional viene una responsabilidad adicional.

---

Debe presionar/publicar cambios cuando estén listos. Por ejemplo, quiero cambiar el nombre de una clase. Esto tocará más de 50 archivos, aunque solo unas pocas líneas. Hago el cambio de nombre usando una herramienta de refactorización.

En un sistema centralizado, ahora tendría que decidir si realmente vale la pena comprometerme solo o si es parte de un trabajo más grande en el que estoy trabajando actualmente. Sin experiencia, las personas suelen elegir la segunda opción, porque no estás seguro de si quieres que sea parte de la historia permanente.

En un sistema distribuido, puedo confirmar el cambio localmente, tengo un historial claro que separa los cambios mecánicos (de refactorización) y el código funcional. En este punto, no afecta a nadie más. Podría revisar fácilmente esa decisión más tarde antes de que finalmente saque mis cambios. Esto será un compromiso limpio por sí mismo entonces.

El problema en este ejemplo es con la siguiente situación: Imagine que cambio el nombre de esa clase en mi sucursal local o mi "confirmación diferida". Mientras tanto, alguien comete un nuevo código en el tronco que usa la clase que acabo de renombrar. Será una molestia fusionar mi cambio de nombre.

Claro que podría haber publicado ese cambio en el momento en que lo hizo. En ambos sistemas. La responsabilidad es la misma. Pero dado que el DVCS lo alienta a tener compromisos más pequeños e incrementales, la fusión será más fácil. Ambos Sistemas podrían haberle brindado la misma "estrategia de salida" de esa situación si publicara sus cambios anticipadamente.

Answer 2

A Integración continua El sistema es una herramienta (como, por ejemplo, Cruise Control) que supervisa el repositorio de código fuente una vez cada N minutos.

Cada vez que algo cambia (alguien comete un código), el CI salta, ejecuta todas las pruebas y luego envía la salida (fallas o no) a algún lugar, como el correo electrónico o una pantalla.

CI no depende en modo alguno del tipo de VCS que utilice, ya sea que esté distribuido o no.

Answer 3

Existen varios elementos para esto, algunos relacionados con el software, algunos relacionados con el proceso.

Los sistemas de control de versiones son solo eso, control de versiones. La capacidad de retroceder, ramificar y fusionar, etc., ya sea que estén centralizados o distribuidos y que ambos tengan lados arriba y abajo. Los VCS per se no lo ayudan a codificar mejor o ejecutar proyectos mejor; facilitan el proceso de desarrollo en equipos si los equipos se ejecutan correctamente. En otras palabras, puedes arruinarlo de forma tan real usando SVN o Mercurial como puedas sin él.

Donde entra CI en lugar de código durante varios días y luego confirmar, luego compilar el proyecto y probar, el codificador se compromete con más frecuencia, 1/2 día 1 día (máximo) y el proyecto está construido y probado (no publicado vivir). Esto significa que cualquier error se recoge antes y se puede rectificar más fácilmente ya que se ha comprometido menos código y la memoria de los programadores está más fresca.

CI se puede hacer de forma manual, o se puede escribir, escribir scripts CLI lo hará, o una de las herramientas de software de CI que se integrarán con CVS se puede configurar para hacer este proceso automática o semiautomáticamente a reducir la gestión y la capacidad de cometer errores.

La ventaja de usar herramientas existentes, Mercurial + Hudson, o SVN y Cruise Control, es que estás aprovechando la sabiduría y la experiencia de personas que probablemente cometieron un error real en algún momento pero aprendieron la lección. Lo que no puedes hacer es sacarlo de la caja y usarlo y esperar que funcione sin agregar tu propio proceso para tu propio proyecto a la mezcla.