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

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

AFAIK, la continuous integration significa comprometerse con el repository central (push) tan pronto como haya probado su código localmente. Al mismo time, 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 vincula estas dos cosas juntas? ¿O estoy equivocado en lo que dije?

EDITAR

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

En los sistemas distribuidos no hay tanto deseo de compromisos 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?

El control de fuente distribuida y la continuous integration no son conceptos mutuamente excluyentes. De hecho, juegan muy bien juntos.

A pesar de que los DVCS están distribuidos por naturaleza, aún tendrá un repository central que representa el "tronco" tradicional que se encuentra en los sistemas de versión centralizada. No debe cambiar su model de desarrollo en términos de cuándo y qué cambios "publica" en su repository 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 necesite interrumpir su trabajo en la característica A para corregir el error B.

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


Debería insert / publicar cambios cuando estén listos. Por ejemplo, quiero cambiar el nombre de una class. Esto tocará más de 50 files, 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 comprometerse por sí mismo 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: imagina que cambio el nombre de esa class en mi sucursal local o mi "confirmación diferida". Mientras tanto, alguien comete un nuevo código en el tronco que usa la class que acabo de renombrar. Será una molestia fusionar mi cambio de nombre.

Claro que podrías haber publicado ese cambio en el momento en que lo hiciste. 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.

Un sistema de continuous integration es una herramienta (como, por ejemplo, Cruise Control) que supervisa el repository 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 testings y luego envía la salida (fallas o no) a algún lugar, como el correo electrónico o una pantalla.

CI no depende de ninguna manera del tipo de VCS que use, ya sea que esté distribuido o no.

Hay una serie de elementos en esto, algunos relacionados con el software, algunos relacionados con el process.

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

Cuando entra CI en lugar de código durante varios días y luego se compromete, luego comstack el proyecto y testing, el codificador se compromete con más frecuencia, 1/2 día 1 día (máximo) y el proyecto se construye y testing (no se libera para vivir). Esto significa que cualquier error se recoge antes y se puede rectificar más fácilmente ya que se ha comprometido less código y la memory de los progtwigdores está más fresca.

El IC se puede hacer manualmente, 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 process de forma automática o semiautomática para networkingucir la administración y la capacidad de cometer errores.

La ventaja de utilizar las 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 process para tu propio proyecto a la mezcla.