Machine Translated by Google

Introducción Diseño Refactorización ágil NoSQL Entrega DSL Acerca de mí ThoughtWorks ! "

Integración continua
La integración continua es una práctica de desarrollo de software en la que los miembros de un equipo integran
su trabajo con frecuencia; por lo general, cada persona integra al menos una vez al día, lo que genera múltiples
integraciones por día. Cada integración se verifica mediante una compilación automatizada (incluida la prueba) para
detectar errores de integración lo más rápido posible. Muchos equipos encuentran que este enfoque conduce a
problemas de integración significativamente reducidos y permite que un equipo desarrolle software cohesivo más
rápidamente. Este artículo es una descripción general rápida de la integración continua que resume la técnica y su uso
actual.

01 de mayo de 2006 Contenido

Martín Cazador Creación de una característica con integración continua

Prácticas de Integración Continua
Mantener un repositorio de origen único.
Automatice la compilación
Haga que su compilación realice
pruebas automáticas Todos se comprometan con la línea
principal todos los días Cada compromiso debe compilar la
Traducciones: Portugués · chino ·
coreano · Francés · chino · checo · línea principal en una máquina de integración Mantenga la
prueba rápida de compilación en un clon del entorno de
Encuentre artículos similares a este producción Facilite que cualquiera obtenga el ejecutable más
mirando estas etiquetas: popular · ágil ·
reciente
entrega · programación extrema ·
integración continua
Todos pueden ver lo que está pasando.
Automatice la implementación
Beneficios de la Integración Continua
Para obtener más información sobre este y Introducción a la integración continua
otros temas relacionados, echa un vistazo a mi pensamientos finales
página de guía para la entrega. Lectura adicional
obras de pensamiento, mi empleador, ofrece
consultoría y soporte en torno a la Integración
Continua. El CruiseControl de código abierto, el primer
servidor de integración continua, se creó originalmente
en ThoughtWorks. Recientemente, ThoughtWorks
Studios, nuestro grupo de productos, lanzó Go , un
nuevo servidor para integración y entrega continuas.
Admite canalizaciones de implementación paralelas con
múltiples proyectos, un panel de control elegante y
soporte para implementaciones automatizadas. Es una
herramienta comercial, pero es de uso gratuito para
configuraciones pequeñas.

Recuerdo vívidamente uno de mis primeros avistamientos de un gran proyecto de software. Estaba haciendo una
pasantía de verano en una gran empresa de electrónica inglesa. Mi gerente, parte del grupo de control de calidad,
me dio un recorrido por un sitio y entramos en un almacén enorme y deprimente lleno de cubos. Me dijeron que este
proyecto había estado en desarrollo durante un par de años y actualmente se estaba integrando, y se había estado
integrando durante varios meses. Mi guía me dijo que nadie sabía realmente cuánto tiempo tomaría terminar de
integrarse. De esto aprendí una historia común de los proyectos de software: la integración es un proceso largo e
impredecible.

Pero este no tiene por qué ser el camino. La mayoría de los proyectos realizados por mis colegas en ThoughtWorks,
Machine Translated by Google
y por muchos otros en todo el mundo, tratan la integración como algo que no es un evento. El trabajo de
cualquier desarrollador individual está a solo unas pocas horas de un estado de proyecto compartido y puede
volver a integrarse en ese estado en minutos. Cualquier error de integración se encuentra rápidamente y se
puede corregir rápidamente.

Este contraste no es el resultado de una herramienta costosa y compleja. La esencia de esto radica en la
práctica simple de que todos los miembros del equipo se integren con frecuencia, generalmente a diario, en
un repositorio de código fuente controlado.

Cuando describo esta práctica a la gente, comúnmente encuentro dos reacciones:

"no puede funcionar (aquí)" y "hacerlo no hará mucha diferencia". Lo que la gente
El artículo original sobre Integración
descubre cuando lo intenta es que es mucho más fácil de lo que parece y que marca continua describe nuestras experiencias
una gran diferencia en el desarrollo. cuando Matt ayudó a organizar la integración
continua en un proyecto de ThoughtWorks en
Por lo tanto, la tercera reacción común es "sí, hacemos eso, ¿cómo podrías vivir sin eso?" el año 2000.

El término 'Integración Continua' se originó con el proceso de desarrollo de Programación Extrema,

como una de sus doce prácticas originales. Cuando comencé en ThoughtWorks, como consultor,
animé al proyecto en el que estaba trabajando a usar la técnica. Matthew Foemmel convirtió mis vagas
exhortaciones en acciones sólidas y vimos que el proyecto pasaba de integraciones raras y complejas a la
ausencia de eventos que describí.
Matthew y yo escribimos nuestra experiencia en la versión original de este artículo, que ha sido uno de
los artículos más populares de mi sitio.

Aunque la integración continua es una práctica que no requiere herramientas particulares para
implementar, hemos encontrado que es útil usar un servidor de integración continua. El servidor de este tipo
más conocido es CruiseControl, una herramienta de código abierto creada originalmente por varias personas
en ThoughtWorks y ahora mantenida por una amplia comunidad. Desde entonces, han aparecido otros
servidores de CI, tanto de código abierto como comerciales, incluido Cruise de los estudios ThoughtWorks.

Creación de una función con integración continua

La forma más fácil es que explique qué es CI y cómo funciona para mostrar un ejemplo rápido de
cómo funciona con el desarrollo de una pequeña función. Supongamos que tengo que hacer algo con una
pieza de software, realmente no importa cuál sea la tarea, por el momento asumiré que es pequeña y que se
puede hacer en unas pocas horas. (Exploraremos tareas más largas y otros problemas más adelante).

Comienzo tomando una copia de la fuente integrada actual en mi máquina de desarrollo local. Hago esto
mediante el uso de un sistema de gestión de código fuente extrayendo una copia de trabajo de la línea
principal.

El párrafo anterior tendrá sentido para las personas que usan sistemas de control de código fuente,
pero será un galimatías para quienes no lo hagan. Así que permítanme explicar rápidamente eso último.
Un sistema de control de código fuente mantiene todo el código fuente de un proyecto en un repositorio.
El estado actual del sistema se suele denominar "línea principal". En cualquier momento, un desarrollador
puede hacer una copia controlada de la línea principal en su propia máquina, esto se llama 'desprotección'.
La copia en la máquina del desarrollador se denomina "copia de trabajo". (La mayoría de las veces actualiza
su copia de trabajo a la línea principal; en la práctica, es lo mismo).

Ahora tomo mi copia de trabajo y hago lo que sea necesario para completar mi tarea. Esto consistirá tanto
en alterar el código de producción, como en agregar o cambiar
Machine Translated by Google
pruebas automatizadas. La integración continua asume un alto grado de pruebas que se automatizan en el
software: una instalación que llamo código de autoevaluación. A menudo, estos utilizan la versión de los
populares marcos de prueba XUnit.

Una vez que termino (y generalmente en varios puntos cuando estoy trabajando), realizo una
compilación automatizada en mi máquina de desarrollo. Esto toma el código fuente en mi copia de trabajo,
lo compila y lo vincula a un ejecutable y ejecuta las pruebas automatizadas.
Solo si todo se compila y prueba sin errores, se considera que la compilación general es buena.

Con una buena compilación, puedo pensar en enviar mis cambios al repositorio.
El giro, por supuesto, es que otras personas pueden, y generalmente lo han hecho, hacer cambios en la línea
principal antes de que yo tenga la oportunidad de comprometerme. Entonces, primero actualizo mi copia de
trabajo con sus cambios y reconstruyo. Si sus cambios chocan con mis cambios, se manifestará como una falla
en la compilación o en las pruebas. En este caso, es mi responsabilidad arreglar esto y repetirlo hasta que
pueda crear una copia de trabajo que esté correctamente sincronizada con la línea principal.

Una vez que he creado mi propia compilación de una copia de trabajo correctamente sincronizada, finalmente
puedo enviar mis cambios a la línea principal, que luego actualiza el repositorio.

Sin embargo, mi compromiso no termina mi trabajo. En este punto volvemos a compilar, pero esta vez en una
máquina de integración basada en el código principal. Solo cuando esta compilación tenga éxito podemos decir
que mis cambios están hechos. Siempre existe la posibilidad de que me haya perdido algo en mi máquina y el
repositorio no se haya actualizado correctamente. Solo cuando mis cambios comprometidos se construyen con
éxito en la integración, mi trabajo está terminado. Esta compilación de integración puede ser ejecutada
manualmente por mí o Cruise puede hacerlo automáticamente.

Si se produce un conflicto entre dos desarrolladores, generalmente se detecta cuando el segundo

desarrollador que se compromete crea su copia de trabajo actualizada. De lo contrario, la compilación de
integración debería fallar. De cualquier manera, el error se detecta rápidamente. En este punto, la tarea más
importante es arreglarlo y hacer que la compilación vuelva a funcionar correctamente. En un entorno de
integración continua, nunca debe tener una compilación de integración fallida que falle por mucho tiempo. Un
buen equipo debe tener muchas construcciones correctas al día. Las compilaciones incorrectas ocurren de
vez en cuando, pero deben corregirse rápidamente.

El resultado de hacer esto es que hay una pieza de software estable que funciona correctamente y contiene
pocos errores. Todo el mundo se desarrolla a partir de esa base estable compartida y nunca se aleja tanto de
esa base que lleva mucho tiempo volver a integrarse con ella. Se dedica menos tiempo a tratar de encontrar
errores porque aparecen rápidamente.

Prácticas de Integración Continua

La historia anterior es una descripción general de CI y cómo funciona en la vida diaria. Lograr que todo esto
funcione sin problemas es obviamente algo más que eso. Me centraré ahora en las prácticas clave que
componen una IC eficaz.

Mantener un repositorio de origen único.

Los proyectos de software involucran muchos archivos que deben organizarse juntos para construir un producto.
Hacer un seguimiento de todos estos es un gran esfuerzo, especialmente cuando hay varias personas
involucradas. Por lo tanto, no sorprende que, a lo largo de los años, los equipos de desarrollo de software hayan
creado herramientas para administrar todo esto. Estas herramientas, denominadas herramientas de
administración de código fuente, administración de configuración, sistemas de control de versiones, repositorios
u otros nombres, son una parte integral de la mayoría de las herramientas de desarrollo.
Machine Translated by Google
proyectos Lo triste y sorprendente es que no forman parte de todos los proyectos. Es raro, pero me encuentro
con proyectos que no usan dicho sistema y usan una combinación desordenada de unidades locales y
compartidas.

Entonces, como base simple, asegúrese de obtener un sistema de administración de código fuente decente.
El costo no es un problema, ya que hay disponibles herramientas de código abierto de buena calidad. El
repositorio de código abierto de elección actual es Subversion. (La antigua herramienta de código abierto CVS
todavía se usa ampliamente y es mucho mejor que nada, pero Subversion es la opción moderna).
Curiosamente, mientras hablo con los desarrolladores, sé que la mayoría de las herramientas
comerciales de administración de código fuente gustan menos que Subversion. La única herramienta por
la que siempre he oído decir que vale la pena pagar es Perforce.

Una vez que obtenga un sistema de administración de código fuente, asegúrese de que sea el lugar
conocido para que todos obtengan el código fuente. Nadie debería preguntar "¿dónde está el archivo foo
whiffle?" Todo debe estar en el repositorio.

Aunque muchos equipos usan repositorios, un error común que veo es que no ponen todo en el repositorio. Si
las personas usan uno, pondrán el código allí, pero todo lo que necesita para hacer una compilación debe estar
allí, incluidos: scripts de prueba, archivos de propiedades, esquema de base de datos, scripts de instalación y
bibliotecas de terceros. He conocido proyectos que verifican sus compiladores en el repositorio (importante en
los primeros días de los compiladores de C ++ escamosos). La regla general básica es que debe poder caminar
hasta el proyecto con una máquina virgen, hacer un pago y poder construir completamente el sistema.

Solo debe haber una cantidad mínima de cosas en la máquina virgen, generalmente cosas que son grandes,
complicadas de instalar y estables. Un sistema operativo, un entorno de desarrollo Java o un sistema de base de
datos base son ejemplos típicos.

Debe poner todo lo necesario para una construcción en el sistema de control de fuente, sin embargo, también
puede poner otras cosas con las que la gente generalmente trabaja allí. Las configuraciones de IDE son
buenas para incluirlas porque de esa manera es fácil para las personas compartir las mismas configuraciones
de IDE.

Una de las características de los sistemas de control de versiones es que le permiten crear múltiples
ramas para manejar diferentes flujos de desarrollo. Esta es una característica útil, incluso esencial, pero con
frecuencia se usa en exceso y mete a la gente en problemas. Mantenga su uso de sucursales al mínimo. En
particular, tiene una línea principal: una sola rama del proyecto actualmente en desarrollo. Prácticamente todo
el mundo debería trabajar fuera de esta línea principal la mayor parte del tiempo. (Las ramas razonables son
correcciones de errores de versiones de producción anteriores y experimentos temporales).

En general, debe almacenar en el control de fuente todo lo que necesita para construir cualquier cosa, pero
nada de lo que realmente construye. Algunas personas mantienen los productos de compilación en control de
fuente, pero considero que es un olor, una indicación de un problema más profundo, generalmente una
incapacidad para recrear compilaciones de manera confiable.

Automatice la construcción

Convertir las fuentes en un sistema en ejecución a menudo puede ser un proceso complicado que involucra la
compilación, mover archivos, cargar esquemas en las bases de datos, etc. Sin embargo, como la mayoría de las
tareas en esta parte del desarrollo de software, puede automatizarse y, como resultado, debería automatizarse.
Pedirle a la gente que escriba comandos extraños o hacer clic en los cuadros de diálogo es una pérdida de
tiempo y un caldo de cultivo para los errores.

Los entornos automatizados para compilaciones son una característica común de los sistemas. El mundo
Unix se ha hecho durante décadas, la comunidad Java desarrolló Ant, el .NET
Machine Translated by Google
comunidad ha tenido Nant y ahora tiene MSBuild. Asegúrese de que puede compilar e iniciar su sistema utilizando
estos scripts con un solo comando.

Un error común es no incluir todo en la compilación automatizada. La compilación debe incluir sacar el esquema
de la base de datos del repositorio y activarlo en el entorno de ejecución. Elaboraré mi regla general anterior:
cualquiera debería poder traer una máquina virgen, verificar las fuentes del repositorio, emitir un solo comando y tener
un sistema en ejecución en su máquina.

Los scripts de compilación vienen en varios sabores y, a menudo, son específicos de una plataforma o
comunidad, pero no tienen por qué serlo. Aunque la mayoría de nuestros proyectos Java usan Ant, algunos han
usado Ruby (el sistema Ruby Rake es una herramienta de script de construcción muy buena). Obtuvimos mucho valor
de la automatización de un proyecto Microsoft COM inicial con Ant.

Una gran compilación a menudo lleva tiempo, no desea realizar todos estos pasos si solo ha realizado un pequeño
cambio. Por lo tanto, es una buena herramienta de compilación que debe cambiarse como parte del proceso. La forma
común de hacer esto es verificar las fechas de los archivos de origen y de objeto y compilar solo si la fecha de origen es
posterior. Las dependencias se vuelven complicadas: si un archivo de objeto cambia, es posible que también sea
necesario reconstruir los que dependen de él.
Los compiladores pueden manejar este tipo de cosas, o no.

Dependiendo de lo que necesite, es posible que necesite diferentes tipos de cosas para construir. Puede construir un
sistema con o sin código de prueba, o con diferentes conjuntos de pruebas. Algunos componentes se pueden construir
de forma independiente. El script de compilación debería permitirle crear objetivos alternativos para diferentes casos.

Muchos de nosotros usamos IDE, y la mayoría de los IDE tienen algún tipo de proceso de administración de
compilación dentro de ellos. Sin embargo, estos archivos siempre son propiedad del IDE y, a menudo, son frágiles.
Además necesitan el IDE para funcionar. Está bien que los usuarios de IDE configuren sus propios archivos de
proyecto y los usen para desarrollo individual. Sin embargo, es esencial tener una compilación maestra que se pueda
usar en un servidor y se pueda ejecutar desde otros scripts. Entonces, en un proyecto de Java, estamos de acuerdo con
que los desarrolladores construyan en su IDE, pero la compilación maestra usa Ant para garantizar que se pueda ejecutar
en el servidor de desarrollo.

Haga que su compilación se autoevalúe

Tradicionalmente, una compilación significa compilar, vincular y todo lo adicional necesario para que un programa se
ejecute. Un programa puede ejecutarse, pero eso no significa que haga lo correcto. Los lenguajes modernos tipificados
estáticamente pueden detectar muchos errores, pero muchos más se escapan de esa red.

Una buena manera de detectar errores de manera más rápida y eficiente es incluir pruebas automatizadas en el proceso
de compilación. Las pruebas no son perfectas, por supuesto, pero pueden detectar muchos errores, suficientes para ser
útiles. En particular, el surgimiento de Extreme Programming (XP) y Test Driven Development (TDD) han hecho mucho
para popularizar el código de autoevaluación y, como resultado, muchas personas han visto el valor de la técnica.

Los lectores habituales de mi trabajo sabrán que soy un gran admirador tanto de TDD como de XP, sin embargo, quiero
enfatizar que ninguno de estos enfoques es necesario para obtener los beneficios del código de autoevaluación. Ambos
enfoques tienen como objetivo escribir pruebas antes de escribir el código que las hace pasar; en este modo, las pruebas
tienen tanto que ver con explorar el diseño del sistema como con detectar errores. Esto es bueno, pero no es necesario
para los propósitos de la integración continua, donde tenemos el requisito más débil del código de autoevaluación.
(Aunque TDD es mi forma preferida de producir código de autoevaluación).

Para el código de autoevaluación, necesita un conjunto de pruebas automatizadas que puedan verificar una gran parte
Machine Translated by Google
del código base para errores. Las pruebas deben poder iniciarse con un comando simple y ser autocontrolables.
El resultado de ejecutar el conjunto de pruebas debe indicar si alguna prueba falló. Para que una compilación se
autoevalúe, la falla de una prueba debe hacer que la compilación falle.

En los últimos años, el auge de TDD ha popularizado la familia XUnit de herramientas de código abierto que
son ideales para este tipo de pruebas. Las herramientas de XUnit han demostrado ser muy valiosas para
nosotros en ThoughtWorks y siempre sugiero a las personas que las usen.
Estas herramientas, iniciadas por Kent Beck, le facilitan mucho la configuración de un entorno de autoevaluación
completo.

Las herramientas de XUnit son sin duda el punto de partida para crear su código de autoevaluación. También
debe buscar otras herramientas que se centren en pruebas más integrales, hay una gran variedad de estas en
este momento, incluidas FIT, selenio, Sahi, agua, APTITUD FÍSICA, y muchos otros que no estoy tratando de
enumerar exhaustivamente aquí.

Por supuesto que no puedes contar con pruebas para encontrar todo. Como se suele decir: las pruebas no
prueban la ausencia de errores. Sin embargo, la perfección no es el único punto en el que se recupera la inversión por
una compilación de autocomprobación. Las pruebas imperfectas, que se ejecutan con frecuencia, son mucho mejores
que las pruebas perfectas que nunca se escriben.

Todos se comprometen con la línea principal todos los días

La integración tiene que ver principalmente con la comunicación. La integración permite a los desarrolladores
informar a otros desarrolladores sobre los cambios que han realizado. La comunicación frecuente permite que las
personas sepan rápidamente a medida que se desarrollan los cambios.

El único requisito previo para que un desarrollador se comprometa con la línea principal es que pueda compilar
correctamente su código. Esto, por supuesto, incluye pasar las pruebas de construcción. Al igual que con cualquier
ciclo de confirmación, el desarrollador primero actualiza su copia de trabajo para que coincida con la línea principal,
resuelve cualquier conflicto con la línea principal y luego construye en su máquina local. Si la compilación pasa,
entonces son libres de comprometerse con la línea principal.

Al hacer esto con frecuencia, los desarrolladores descubren rápidamente si hay un conflicto entre dos desarrolladores.
La clave para solucionar problemas rápidamente es encontrarlos rápidamente. Con los desarrolladores
comprometiéndose cada pocas horas, se puede detectar un conflicto a las pocas horas de que ocurra, en ese
momento no ha sucedido mucho y es fácil de resolver. Los conflictos que pasan desapercibidos durante semanas
pueden ser muy difíciles de resolver.

El hecho de que construyas cuando actualices tu copia de trabajo significa que detectas conflictos de compilación
así como conflictos textuales. Dado que la compilación es de autoevaluación, también detecta conflictos en la ejecución
del código. Los últimos conflictos son errores particularmente difíciles de encontrar si pasan mucho tiempo sin ser
detectados en el código. Dado que solo hay unas pocas horas de cambios entre confirmaciones, solo hay tantos lugares
donde el problema podría estar escondido. Además, dado que no ha cambiado mucho, puede usar la depuración de
diferencias para ayudarlo a encontrar el error.

Mi regla general es que todos los desarrolladores deben comprometerse con el repositorio todos los días. En la
práctica, a menudo es útil si los desarrolladores se comprometen con más frecuencia que eso.
Cuanto más a menudo se comprometa, menos lugares tendrá para buscar errores de conflicto y más rápidamente
solucionará los conflictos.

Las confirmaciones frecuentes animan a los desarrolladores a dividir su trabajo en pequeños fragmentos de unas
pocas horas cada uno. Esto ayuda a seguir el progreso y proporciona una sensación de progreso. A menudo ayuda a
las personas a sentir inicialmente que no pueden hacer algo significativo en solo unas pocas horas, pero hemos
descubierto que la tutoría y la práctica aprenden.
Machine Translated by Google
Cada compromiso debe construir la línea principal en una máquina de integración

Mediante confirmaciones diarias, el equipo obtiene compilaciones probadas con frecuencia. Esto debería significar
que la línea principal se mantiene en un estado saludable. En la práctica, sin embargo, las cosas siguen saliendo
mal. Una de las razones es la disciplina, las personas no actualizan ni construyen antes de comprometerse.
Otro son las diferencias ambientales entre las máquinas de los desarrolladores.

Como resultado, debe asegurarse de que se realicen compilaciones regulares en una máquina de integración y
solo si esta compilación de integración tiene éxito, se debe considerar que se ha realizado la confirmación. Dado
que el desarrollador que se compromete es responsable de esto, ese desarrollador debe monitorear la compilación
de la línea principal para poder arreglarla si se rompe. Un corolario de esto es que no debe irse a casa hasta que la
compilación de la línea principal haya pasado con cualquier confirmación que haya agregado al final del día.

Hay dos formas principales que he visto para garantizar esto: usar una compilación manual o un
servidor de integración continua.

El enfoque de compilación manual es el más simple de describir. Esencialmente, es algo similar a la compilación
local que hace un desarrollador antes de la confirmación en el repositorio.
El desarrollador va a la máquina de integración, revisa el encabezado de la línea principal (que ahora alberga su
última confirmación) y comienza la compilación de integración. Mantiene un ojo en su progreso, y si la compilación
tiene éxito, habrá terminado con su compromiso. (Véase también la descripción de Jim Shore .)

El servidor de integración continua actúa como un monitor para el repositorio. Cada vez que finaliza una
confirmación contra el repositorio, el servidor verifica automáticamente las fuentes en la máquina de
integración, inicia una compilación y notifica al encargado de confirmación el resultado de la compilación. El
committer no termina hasta que recibe la notificación, generalmente un correo electrónico.

En ThoughtWorks, somos grandes admiradores de los servidores de integración continua; de hecho, lideramos el
desarrollo original de CruiseControl. y CruiseControl.NET, los servidores CI de código abierto ampliamente utilizados.
Desde entonces también hemos construido el crucero comercial servidor CI. Usamos un servidor CI en casi todos los

proyectos que hacemos y estamos muy contentos con los resultados.

No todos prefieren usar el servidor CI. Jim Shore dio una buena descripción de por qué prefiere el enfoque
manual. Estoy de acuerdo con él en que CI es mucho más que instalar algún software. Todas las prácticas aquí
deben estar en juego para hacer la Integración Continua de manera efectiva. Pero igualmente, muchos equipos que
hacen CI bien encuentran que un servidor de CI es una herramienta útil.

Muchas organizaciones realizan compilaciones regulares en un horario cronometrado, como todas las noches. Esto
no es lo mismo que una compilación continua y no es suficiente para la integración continua.
El objetivo de la integración continua es encontrar los problemas tan pronto como sea posible.
Las compilaciones nocturnas significan que los errores permanecen sin ser detectados durante todo un día antes de
que alguien los descubra. Una vez que están en el sistema tanto tiempo, lleva mucho tiempo encontrarlos y eliminarlos.

Una parte clave de hacer una compilación continua es que si la compilación de la línea principal falla, debe
corregirse de inmediato. El objetivo de trabajar con CI es que siempre se está desarrollando sobre una base estable
conocida. No es malo que la compilación de la línea principal se rompa, aunque si sucede todo el tiempo, sugiere
que las personas no están siendo lo suficientemente cuidadosas para actualizar y compilar localmente antes de
una confirmación. Sin embargo, cuando la compilación de la línea principal se rompe, es importante que se arregle
rápidamente. Para ayudar a evitar romper la línea principal, puede considerar usar una cabeza pendiente.

Cuando los equipos están introduciendo IC, a menudo esta es una de las cosas más difíciles de resolver.
Machine Translated by Google
Al principio, un equipo puede tener dificultades para adquirir el hábito regular de trabajar con compilaciones principales,
especialmente si están trabajando en una base de código existente. La paciencia y la aplicación constante parecen
funcionar con regularidad, así que no te desanimes.

Mantenga la construcción rápida

El objetivo de la integración continua es proporcionar una retroalimentación rápida. Nada chupa la sangre de una actividad
de CI más que una construcción que lleva mucho tiempo. Aquí debo admitir cierta diversión cascarrabias de un viejo en
lo que se considera una construcción larga. La mayoría de mis colegas consideran que una compilación que toma una
hora es totalmente irrazonable. Recuerdo que los equipos soñaban que podían hacerlo tan rápido y, de vez en cuando,
todavía nos encontramos con casos en los que es muy difícil conseguir compilaciones a esa velocidad.

Sin embargo, para la mayoría de los proyectos, la pauta de XP de una compilación de diez minutos está perfectamente
dentro de lo razonable. La mayoría de nuestros proyectos modernos logran esto. Vale la pena hacer un esfuerzo
concentrado para que esto suceda, porque cada minuto que reduce el tiempo de compilación es un minuto ahorrado
para cada desarrollador cada vez que se compromete. Dado que CI exige confirmaciones frecuentes, esto suma mucho
tiempo.

Si está pensando en un tiempo de compilación de una hora, llegar a una compilación más rápida puede parecer una
perspectiva desalentadora. Incluso puede ser desalentador trabajar en un nuevo proyecto y pensar en cómo acelerar
las cosas. Para las aplicaciones empresariales, al menos, hemos encontrado que el cuello de botella habitual son las
pruebas, en particular las pruebas que involucran servicios externos como una base de datos.

Probablemente, el paso más crucial sea comenzar a trabajar en la configuración de una canalización de implementación.
La idea detrás de una canalización de implementación (también conocida como canalización de compilación
o compilación por etapas) es que, de hecho, hay varias compilaciones realizadas en secuencia. El compromiso
con la línea principal desencadena la primera compilación, lo que yo llamo la compilación de compromiso. La compilación
de compromiso es la compilación que se necesita cuando alguien se compromete con la línea principal. La compilación

de confirmación es la que debe realizarse rápidamente, como resultado, se necesitarán varios atajos que reducirán la
capacidad de detectar errores. El truco consiste en equilibrar las necesidades de detección de errores y velocidad para
que una buena compilación de confirmación sea lo suficientemente estable para que otras personas puedan trabajar en ella.

Una vez que la compilación de confirmación es buena, otras personas pueden trabajar en el
código con confianza. Sin embargo, hay otras pruebas más lentas que puede empezar a
Jez Humble y Dave Farley ampliaron
hacer. Las máquinas adicionales pueden ejecutar más rutinas de prueba en la compilación estas ideas al tema de la entrega continua,
que toman más tiempo. con más detalles sobre el concepto de
canales de implementación. Su libro,
Continuous Delivery, ganó con razón el
Un ejemplo simple de esto es una canalización de implementación de dos etapas. La primera premio a la excelencia Jolt en 2011.
etapa haría la compilación y ejecutaría pruebas que son pruebas unitarias más localizadas con la
base de datos completamente desconectada. Estas pruebas pueden ejecutarse muy rápido,
manteniéndose dentro de la pauta de diez minutos. Sin embargo, no se encontrarán errores que involucren interacciones
a mayor escala, particularmente aquellos que involucren la base de datos real. La compilación de la segunda etapa
ejecuta un conjunto diferente de pruebas que afectan a la base de datos real e implica un comportamiento más integral.
Esta suite puede tardar un par de horas en ejecutarse.

En este escenario, las personas usan la primera etapa como compilación de confirmación y la usan como su ciclo
principal de CI. La compilación de la segunda etapa se ejecuta cuando puede, recogiendo el ejecutable de la última
compilación de confirmación buena para realizar más pruebas. Si esta compilación secundaria falla, es posible que
no tenga la misma calidad de 'detener todo', pero el equipo tiene como objetivo corregir dichos errores lo más rápido
posible, mientras mantiene la compilación de confirmación en ejecución. Como en este ejemplo, las compilaciones
posteriores suelen ser pruebas puras, ya que en estos días suelen ser las pruebas las que causan la lentitud.
Machine Translated by Google
Si la compilación secundaria detecta un error, eso es una señal de que la compilación confirmada podría
funcionar con otra prueba. En la medida de lo posible, desea asegurarse de que cualquier falla en una etapa
posterior conduzca a nuevas pruebas en la compilación de confirmación que habrían detectado el error, de
modo que el error permanezca fijo en la compilación de confirmación. De esta manera, las pruebas de
compromiso se fortalecen cada vez que algo las supera. Hay casos en los que no hay forma de crear una prueba
de ejecución rápida que exponga el error, por lo que puede decidir probar solo esa condición en la compilación
secundaria. La mayoría de las veces, afortunadamente, puede agregar pruebas adecuadas a la compilación de
confirmación.

Este ejemplo es de una tubería de dos etapas, pero el principio básico se puede extender a cualquier cantidad
de etapas posteriores. Las compilaciones posteriores a la compilación de confirmación también se pueden
realizar en paralelo, por lo que si tiene dos horas de pruebas secundarias, puede mejorar la capacidad de
respuesta al tener dos máquinas que ejecutan la mitad de las pruebas cada una. Al usar compilaciones
secundarias paralelas como esta, puede introducir todo tipo de pruebas automatizadas adicionales, incluidas las
pruebas de rendimiento, en el proceso de compilación regular.

Prueba en un clon del entorno de producción

El objetivo de las pruebas es eliminar, en condiciones controladas, cualquier problema que el sistema pueda
tener en producción. Una parte importante de esto es el entorno en el que se ejecutará el sistema de producción.
Si prueba en un entorno diferente, cada diferencia genera un riesgo de que lo que sucede durante la prueba no
suceda en producción.

Como resultado, desea configurar su entorno de prueba para que sea una imitación lo más exacta posible
de su entorno de producción. Utilice el mismo software de base de datos, con las mismas versiones, utilice la
misma versión del sistema operativo. Coloque todas las bibliotecas apropiadas que se encuentran en el entorno
de producción en el entorno de prueba, incluso si el sistema no las usa realmente. Use las mismas direcciones
IP y puertos, ejecútelo en el mismo hardware.

Bueno, en realidad hay límites. Si está escribiendo software de escritorio, no es factible probar en un clon de
cada escritorio posible con todo el software de terceros que ejecutan diferentes personas. Del mismo modo,
algunos entornos de producción pueden ser prohibitivamente caros de duplicar (aunque a menudo me he
encontrado con economías falsas al no duplicar entornos moderadamente caros). A pesar de estos límites, su
objetivo aún debe ser duplicar el entorno de producción tanto como pueda y comprender los riesgos que está
aceptando para cada diferencia entre la prueba y la producción.

Si tiene una configuración bastante simple sin muchas comunicaciones incómodas, es posible que pueda
ejecutar su compilación de confirmación en un entorno imitado. Sin embargo, a menudo es necesario utilizar
dobles de prueba porque los sistemas responden de forma lenta o intermitente. Como resultado, es común
tener un entorno muy artificial para las pruebas de confirmación de velocidad y usar un clon de producción
para las pruebas secundarias.

He notado un interés creciente en el uso de la virtualización para facilitar la creación de entornos de prueba.
Las máquinas virtualizadas se pueden guardar con todos los elementos necesarios integrados en la virtualización.
Entonces es relativamente sencillo instalar la última compilación y ejecutar pruebas. Además, esto puede
permitirle ejecutar varias pruebas en una máquina o simular varias máquinas en una red en una sola máquina.
A medida que disminuye la penalización de rendimiento de la virtualización, esta opción hace cada vez más

sentido.

Facilite que cualquiera obtenga el último ejecutable

Una de las partes más difíciles del desarrollo de software es asegurarse de construir
Machine Translated by Google
el software adecuado. Hemos descubierto que es muy difícil especificar lo que quiere por adelantado y
ser correcto; A la gente le resulta mucho más fácil ver algo que no está del todo bien y decir cómo debe cambiarse.
Los procesos de desarrollo ágil esperan y aprovechan explícitamente esta parte del comportamiento humano.

Para ayudar a que esto funcione, cualquier persona involucrada en un proyecto de software debe poder obtener el
ejecutable más reciente y poder ejecutarlo: para demostraciones, pruebas exploratorias o simplemente para ver qué
cambió esta semana.

Hacer esto es bastante sencillo: asegúrese de que haya un lugar conocido donde las personas puedan
encontrar el ejecutable más reciente. Puede ser útil colocar varios ejecutables en dicho almacén. Para lo último,
debe poner el ejecutable más reciente para pasar las pruebas de confirmación; dicho ejecutable debería ser
bastante estable siempre que el conjunto de confirmación sea razonablemente sólido.

Si está siguiendo un proceso con iteraciones bien definidas, por lo general es aconsejable colocar allí también el
final de las compilaciones de iteración. Las demostraciones, en particular, necesitan un software cuyas
características sean familiares, por lo que generalmente vale la pena sacrificar lo último por algo que el demostrador
sepa cómo operar.

Todos pueden ver lo que está pasando.

La integración continua tiene que ver con la comunicación, por lo que desea asegurarse de que todos
puedan ver fácilmente el estado del sistema y los cambios que se le han realizado.

Una de las cosas más importantes para comunicar es el estado de la compilación de la línea principal. Si está
utilizando Cruise, hay un sitio web incorporado que le mostrará si hay una compilación en progreso y cuál fue el
estado de la última compilación principal. A muchos equipos les gusta hacer que esto sea aún más evidente al
conectar una pantalla continua al sistema de compilación: las luces que brillan en verde cuando la compilación
funciona o en rojo si falla son populares. Un toque particularmente común son las lámparas de lava rojas y verdes ,
que no solo indican el estado de la construcción, sino también cuánto tiempo ha estado en ese estado. Las burbujas
en una lámpara roja indican que la construcción se ha roto durante demasiado tiempo. Cada equipo toma sus propias
decisiones sobre estos sensores de construcción; es bueno jugar con su elección (recientemente vi a alguien
experimentando con un conejo bailarín).

Si está utilizando el manual de procesos de CI, esta visibilidad sigue siendo esencial. El monitor de la máquina
de compilación física puede mostrar el estado de la compilación principal. A menudo tienes una ficha de
construcción para poner en el escritorio de quien sea que esté haciendo la construcción actualmente (una vez
más, algo tonto como un pollo de goma es una buena opción). A menudo, a las personas les gusta hacer un
ruido simple en buenas construcciones, como tocar una campana.

Las páginas web de los servidores de CI pueden contener más información que esta, por supuesto. Cruise
proporciona una indicación no solo de quién está construyendo, sino también de los cambios realizados. Cruise
también proporciona un historial de cambios, lo que permite a los miembros del equipo tener una buena idea de la
actividad reciente en el proyecto. Conozco a líderes de equipo a los que les gusta usar esto para tener una idea de
lo que la gente ha estado haciendo y mantener una idea de los cambios en el sistema.

Otra ventaja de usar un sitio web es que aquellos que no comparten el mismo lugar pueden tener una idea del
estado del proyecto. En general, prefiero que todos trabajen activamente en un proyecto sentados juntos, pero a
menudo hay personas periféricas a las que les gusta vigilar las cosas. También es útil para que los grupos
agreguen información de compilación de varios proyectos, lo que proporciona un estado simple y automatizado de
diferentes proyectos.

Las buenas pantallas de información no son solo las de las pantallas de las computadoras. Una de mis
exhibiciones favoritas fue para un proyecto que estaba entrando en CI. Tenía una larga historia de
Machine Translated by Google
ser incapaz de hacer construcciones estables. Pusimos un calendario en la pared que mostraba un año
completo con un pequeño cuadrado para cada día. Todos los días, el grupo de control de calidad colocaría
una etiqueta verde en el día si habían recibido una compilación estable que pasó las pruebas de
confirmación, de lo contrario, un cuadrado rojo. Con el tiempo, el calendario reveló el estado del proceso de
construcción mostrando una mejora constante hasta que los cuadrados verdes se hicieron tan comunes que
el calendario desapareció: cumplió su propósito.

Automatice la implementación

Para realizar la integración continua, necesita varios entornos, uno para ejecutar pruebas de
confirmación, uno o más para ejecutar pruebas secundarias. Dado que está moviendo ejecutables entre
estos entornos varias veces al día, querrá hacerlo automáticamente. Por lo tanto, es importante tener
scripts que le permitan implementar fácilmente la aplicación en cualquier entorno.

Una consecuencia natural de esto es que también debe tener scripts que le permitan implementar en
producción con una facilidad similar. Es posible que no realice implementaciones en producción todos
los días (aunque me he encontrado con proyectos que lo hacen), pero la implementación automática
ayuda a acelerar el proceso y reducir los errores. También es una opción económica, ya que solo usa
las mismas capacidades que usa para implementar en entornos de prueba.

Si implementa en producción una capacidad automatizada adicional que debe

considerar es la reversión automatizada. De vez en cuando suceden cosas malas,
Mucha gente está preocupada por cómo manejar
y si las sustancias marrones malolientes golpean el metal giratorio, es bueno poder las bases de datos con lanzamientos frecuentes.
volver rápidamente al último estado bueno conocido. Ser capaz de revertir Pramod Sadalage y yo escribimos este artículo
explicando cómo manejar esto con la refactorización
automáticamente también reduce en gran medida la tensión de la implementación, lo automatizada y la migración de bases de datos.
que anima a las personas a implementar con más frecuencia y, por lo tanto, ofrecer
nuevas funciones a los usuarios rápidamente. (La comunidad de Ruby on Rails
desarrolló una herramienta llamada Capistrano que es un buen ejemplo de una
herramienta que hace este tipo de cosas).

En entornos agrupados, he visto implementaciones continuas en las que el nuevo software se

implementa en un nodo a la vez, reemplazando gradualmente la aplicación en el transcurso de unas pocas
horas.

Una variación particularmente interesante de esto que encontré con la aplicación web pública es la
idea de implementar una compilación de prueba para un subconjunto de usuarios. Luego, el equipo ve
cómo se usa la compilación de prueba antes de decidir si implementarla para la población completa de
usuarios. Esto le permite probar nuevas funciones e interfaces de usuario antes de comprometerse con
una elección final. La implementación automatizada, vinculada a una buena disciplina de CI, es esencial
para que esto funcione.

Beneficios de la Integración Continua

En general, creo que el mayor y más amplio beneficio de la integración continua es la reducción
del riesgo. Mi mente todavía flota de regreso a ese proyecto de software temprano que mencioné en
mi primer párrafo. Allí estaban al final (esperaban) de un largo proyecto, pero sin una idea real de cuánto
tiempo pasaría antes de que terminaran.

El problema con la integración diferida es que es muy difícil predecir cuánto tiempo llevará hacerlo y, lo
que es peor, es muy difícil ver qué tan avanzado está el proceso. El resultado es que te estás poniendo
en un punto ciego completo justo en una de las partes más tensas de un proyecto, incluso si eres uno de
los raros casos en los que aún no llegas tarde.
Machine Translated by Google
La integración continua soluciona por completo este problema. No hay una integración larga, eliminas por
completo el punto ciego. En todo momento sabes dónde estás, qué funciona, qué no, los bugs pendientes que
tienes en tu sistema.

Errores: estas son las cosas desagradables que destruyen la confianza y arruinan los horarios y la reputación.
Los errores en el software implementado hacen que los usuarios se enojen contigo. Los errores en el trabajo en
progreso se interponen en su camino, lo que dificulta que el resto del software funcione correctamente.

Las integraciones continuas no eliminan los errores, pero los hacen mucho más fáciles de encontrar y eliminar.
En este sentido, es más bien como un código de autocomprobación. Si introduce un error y lo detecta
rápidamente, es mucho más fácil deshacerse de él. Dado que solo ha cambiado una pequeña parte del sistema,
no tiene que buscar muy lejos. Dado que esa parte del sistema es la parte con la que acaba de trabajar, está
fresca en su memoria, lo que nuevamente hace que sea más fácil encontrar el error. También puede usar la
depuración de diferencias : comparar la versión actual del sistema con una anterior que no tenía el error.

Los errores también son acumulativos. Cuantos más errores tenga, más difícil será eliminar cada uno. Esto
se debe en parte a que obtiene interacciones de errores, donde las fallas se muestran como resultado de múltiples
fallas, lo que hace que cada falla sea más difícil de encontrar. También es psicológico: las personas tienen menos
energía para encontrar y deshacerse de los errores cuando hay muchos de ellos, un fenómeno que los
programadores pragmáticos llaman el síndrome de las ventanas rotas.

Como resultado, los proyectos con integración continua tienden a tener muchísimo menos errores, tanto en
producción como en proceso. Sin embargo, debo enfatizar que el grado de este beneficio está directamente
relacionado con qué tan bueno es su conjunto de pruebas. Debería descubrir que no es demasiado difícil crear
un conjunto de pruebas que marque una diferencia notable. Sin embargo, por lo general, toma un tiempo antes
de que un equipo realmente llegue al nivel bajo de errores que tiene el potencial de alcanzar. Llegar allí significa
trabajar constantemente y mejorar sus pruebas.

Si tiene integración continua, elimina una de las mayores barreras para la implementación frecuente. La
implementación frecuente es valiosa porque les permite a los usuarios obtener nuevas funciones más rápidamente,
brindar comentarios más rápidos sobre esas funciones y, en general, ser más colaborativos en el ciclo de
desarrollo. Esto ayuda a romper las barreras entre los clientes y el desarrollo, barreras que, en mi opinión, son las
mayores barreras para el éxito del desarrollo de software.

Introducción a la integración continua

Entonces, ¿te apetece probar la integración continua? ¿Por dónde empiezas? El conjunto completo de
prácticas que describí anteriormente le brinda todos los beneficios, pero no necesita comenzar con todos ellos.

No hay una receta fija aquí; mucho depende de la naturaleza de su configuración y equipo.
Pero aquí hay algunas cosas que hemos aprendido para poner las cosas en marcha.

Uno de los primeros pasos es automatizar la compilación. Obtenga todo lo que necesita en el control de
fuente para que pueda construir todo el sistema con un solo comando.
Para muchos proyectos, esto no es una tarea menor, pero es esencial para que cualquiera de las otras
cosas funcione. Inicialmente, solo puede compilar ocasionalmente a pedido, o simplemente hacer una
compilación nocturna automatizada. Si bien estos no son una integración continua, una compilación nocturna
automatizada es un buen paso en el camino.

Introduce algunas pruebas automatizadas en tu compilación. Trate de identificar las áreas principales
Machine Translated by Google
donde las cosas van mal y obtenga pruebas automatizadas para exponer esas fallas. En particular, en un proyecto
existente, es difícil obtener un conjunto de pruebas realmente bueno que funcione rápidamente; se necesita tiempo
para desarrollar las pruebas. Sin embargo, debe comenzar en algún lugar: se aplican todos esos clichés sobre el
cronograma de construcción de Roma.

Intente acelerar la compilación de confirmación. La integración continua en una compilación de unas pocas horas
es mejor que nada, pero llegar a ese número mágico de diez minutos es mucho mejor. Esto generalmente requiere
una cirugía bastante seria en su base de código para romper las dependencias en partes lentas del sistema.

Si está iniciando un nuevo proyecto, comience con la integración continua desde el principio. Esté
atento a los tiempos de construcción y tome medidas tan pronto como comience a ir más lento que la regla
de los diez minutos. Si actúa con rapidez, realizará las reestructuraciones necesarias antes de que el código
base se vuelva tan grande que se convierta en un gran problema.

Sobre todo busca ayuda. Encuentre a alguien que haya hecho Integración Continua antes para que lo ayude.
Como cualquier técnica nueva, es difícil introducirla cuando no sabes cómo será el resultado final. Puede costar
dinero conseguir un mentor, pero también pagará en tiempo y productividad perdidos si no lo hace. (Descargo de
responsabilidad / Anuncio: sí, en ThoughtWorks hacemos consultoría en esta área. Después de todo, hemos
cometido la mayoría de los errores que se pueden cometer).

Pensamientos finales

En los años transcurridos desde que Matt y yo escribimos el artículo original en este sitio, la integración
continua se ha convertido en una técnica principal para el desarrollo de software. Casi ningún proyecto de
ThoughtWorks funciona sin él, y vemos a otros que usan CI en todo el mundo. Casi nunca he escuchado cosas
negativas sobre el enfoque, a diferencia de algunas de las prácticas de programación extrema más controvertidas.

Si no está utilizando la integración continua, le recomiendo encarecidamente que lo pruebe. Si es así, tal vez
hay algunas ideas en este artículo que pueden ayudarlo a hacerlo de manera más efectiva.
Hemos aprendido mucho sobre la Integración Continua en los últimos años, espero que aún haya más por
aprender y mejorar.

Otras lecturas
Un ensayo como este no puede cubrir mucho terreno, pero este es un tema importante, así que he creado una
página de guía. en mi sitio web para señalarle más información.

Para explorar la integración continua con más detalle, sugiero echar un vistazo al libro de Paul Duvall
titulado apropiadamente sobre el tema (que ganó un premio Jolt, más de lo que he logrado). Para obtener más
información sobre el proceso más amplio de Entrega continua, eche un vistazo al libro de Jez Humble y Dave
Farley, que también me ganó un premio Jolt.

También puede encontrar más información sobre la integración continua en el sitio de ThoughtWorks .
Machine Translated by Google

Para artículos sobre temas similares…

…echa un vistazo a las siguientes etiquetas:

programación extrema de entrega ágil popular

integración continua

Expresiones de gratitud

En primer lugar, a Kent Beck ya mis muchos colegas en el proyecto Chrysler Comprehensive Compensation (C3). Esta fue mi primera
oportunidad de ver la integración continua en acción con una cantidad significativa de pruebas unitarias. Me mostró lo que era posible y me
dio una inspiración que me guió durante muchos años.

Gracias a Matt Foemmel, Dave Rice y todos los demás que crearon y mantuvieron la integración continua en Atlas. Ese proyecto fue una
señal de CI a mayor escala y mostró los beneficios que le reportó a un proyecto existente.

Paul Julius, Jason Yip, Owen Rodgers, Mike Roberts y otros colaboradores de código abierto han participado en la construcción
de alguna variante de CruiseControl. Aunque el servidor de CI no es esencial, la mayoría de los equipos lo encuentran útil.
CruiseControl y otros servidores de CI han jugado un papel importante en la popularización y habilitación de los desarrolladores de
software para usar la integración continua.

Una de las razones por las que trabajo en ThoughtWorks es para tener un buen acceso a proyectos prácticos realizados por personas
con talento. Casi todos los proyectos que he visitado me han dado sabrosos bocados de información de integración continua.

Revisiones significativas

1 de mayo de 2006: reescritura completa del artículo para actualizarlo y aclarar la descripción del enfoque.

10 de septiembre de 2000: Publicación de la versión original.

guías articulos populares libros Secciones del sitio

introducción
Nueva metodología NoSQL destilado Preguntas más frecuentes

diseño Inyección de dependencia Idiomas específicos del dominio Índice de contenido

ágil Los simulacros no son stubs refactorización bliki
No SQL ¿Ha muerto el diseño? Patrones de arquitectura de aplicaciones empresariales libros
ADSL Integración UML destilado Catálogo ADSL
entrega continua Patrones de análisis Catálogo EAA
Acerca de Planificación Programación extrema Desarrollador EAA

Me Serie de la firma fotos

Trabajos de pensamiento

blogs
carreras
mezclar
girar
Vamos

© Martín Fowler | Política de Privacidad | revelaciones