En los inicios del desarrollo de software, en la mayoría de los casos el código fue escrito por un grupo relativamente pequeño de desarrolladores, que a menudo trabajaban en la misma ubicación y estaban en contacto frecuente. La coordinación y división de responsabilidades se realizaba de manera sencilla.
Los sistemas de control de versiones se desarrollaron hace mucho tiempo para dar cabida a diferentes participantes y colaboradores en un proyecto. Por lo general, hay un repositorio central que almacena la copia maestra de un proyecto, con uno o más desarrolladores que poseen la capacidad de realizar cambios y luego registrarlos.
Las cosas se complican cuando hay muchos desarrolladores, trabajando en muchas ubicaciones diferentes, en un proyecto con muchos subsistemas. El kernel de Linux fue el primer proyecto de desarrollo distribuido realmente enorme, y su creador, Linus Torvalds, inventó el sistema git para racionalizarlo.
Sin embargo, un sistema de control de versiones no garantiza que lo que hace un grupo diverso de colaboradores en conjunto realmente funcione, o que un conjunto de código nuevo o correcciones de errores no entren en conflicto. Eso solo se puede hacer probando.
Durante la prueba, se deben tener en cuenta los siguientes factores:
• ¿Se pueden aplicar simultáneamente conjuntos de cambios superpuestos o entran en conflicto? (un buen sistema de control de versiones como git puede manejar la mayor parte de este trabajo, pero a menudo requiere la intervención humana)
• Cuando se aplican todos los cambios, ¿se compila el proyecto? Por ejemplo, un conjunto de parches puede eliminar un archivo de encabezado que otro necesita. Esto no es detectado por el sistema de control de versiones.
• ¿Funciona en todos los objetivos posibles? Eso podría significar hardware diferente (por ejemplo, x86 frente a ARM) o diferentes sistemas operativos (por ejemplo, Linux frente a Solaris o Windows) o diferentes versiones de bibliotecas utilizadas, idiomas o herramientas.
• ¿Cuándo se considera que una versión pasa la prueba? ¿Existen conjuntos de pruebas no triviales que puedan ejercer una carga de trabajo lo suficientemente representativa como para dar confianza en que todo está bien?
Las técnicas de integración continua garantizan que las pruebas sean tan frecuentes que ningún problema pueda persistir por mucho tiempo y que los desarrolladores del código permanezcan aún en la comunidad.
Los proyectos absorben los cambios rápidamente y en tiempo real (en algunos casos varias veces al día) y ejecutan pruebas automatizadas para asegurarse de que todo esté en armonía.