Integración continua

Los equipos que practican la integración continua buscan dos objetivos:

  • Minimizar la duración y el esfuerzo requerido por cada episodio de integración.
  • Ser capaz de entregar una versión del producto adecuada para su lanzamiento en cualquier momento.

En la práctica, este doble objetivo requiere un procedimiento de integración que, como mínimo, sea reproducible y esté ampliamente automatizado. Esto se logra a través de herramientas de control de versiones, políticas de equipo y convenciones, y herramientas específicamente diseñadas para ayudar a lograr una integración continua.

Obstáculos comunes

  • Como se ha sugerido anteriormente, la práctica de la integración continua no debe confundirse con las herramientas que la asisten (servidores CI como Cruise Control, Hudson, etc.). La integración continua es, ante todo, una cuestión de actitud más que de herramientas, y se basa en más de un tipo de herramienta: herramientas para pruebas, herramientas para automatizar los procesos de construcción y herramientas para el control de versiones.
  • La integración continua tiene como objetivo disminuir el dolor de la integración aumentando su frecuencia. Por lo tanto, “cualquier” esfuerzo relacionado con la producción de versiones intermedias, y que el equipo experimenta como particularmente oneroso, es candidato a ser incluido en el proceso continuo de integración del equipo. (Este es el razonamiento que lleva a los equipos a un despliegue continuo).

Orígenes

  • 1993: La frase “integración continua” ya está en uso y por lo tanto es anterior a lo que más tarde se conocerá como procesos ágiles, por ejemplo un artículo la contrasta con la integración “programada”, y recomienda esta última, citando la “falta de pruebas exhaustivas” como un problema de integración continua; esto ayuda a explicar por qué las pruebas automatizadas favorecidas por los equipos ágiles son un facilitador de la integración continua.
  • 1996: Steve McConnell describe la técnica “Daily Build and Smoke Test”, utilizada en Microsoft para Windows NT 3.0 durante los años 90; el énfasis no está tanto en la automatización como en la frecuencia, siendo el ciclo diario considerado en ese momento “extremo”.
  • 1998: La integración continua es una de las principales prácticas de Extreme Programming .
  • 2000: Un artículo de Martin Fowler ofrece quizás la descripción más completa de la práctica de integración continua disponible en ese momento.
  • 2001: Cruise Control, el primer “servidor de integración continua”, se publica bajo una licencia de código abierto; automatiza la monitorización del repositorio de código fuente, activando el proceso de construcción y prueba, las notificaciones de los resultados a los desarrolladores y el archivo de los informes de prueba; en el periodo 2001-2007 aparece un gran número de herramientas similares, lo que puede llevar a que se preste más atención a las herramientas que a la práctica.
  • 2004: Un artículo de Alberto Savoia propone “Dispositivos de retroalimentación extrema” como lámparas de lava o monitores dedicados, para mostrar los resultados de la integración más reciente, una innovación importante en CI.

Señales de uso

Para la mayoría de los equipos, la integración continua en la práctica equivale a lo siguiente:

  • Uso de una herramienta de control de versiones (CVS, SVN, Git, etc.)
  • Un proceso automatizado de construcción y lanzamiento de productos.
  • Instrumentación del proceso de construcción para activar la unidad y pruebas de aceptación “cada vez que se publique cualquier cambio en el control de versiones”.
  • En el caso de que incluso una sola prueba falle, alertar al equipo de una “construcción rota” para que el equipo pueda alcanzar una línea de base estable y liberable de nuevo lo antes posible.
  • Opcionalmente, el uso de una herramienta como un servidor de integración continua, que automatiza el proceso de integración, prueba y reporte de los resultados de las pruebas.

Busque una pantalla dedicada en un lugar prominente de la sala del equipo: puede ser una pantalla normal, una pantalla LED o incluso una lámpara de lava, con el único propósito de informar sobre el resultado de la integración más reciente.

Observe también cómo responde el equipo a una construcción rota, lo que sugiere que se puede haber detectado un defecto. Si el equipo es consciente de los defectos, pero los tolera o continúa trabajando en un producto que no está en estado de publicación, el término integración continua ya no se aplica, ¡independientemente de las herramientas!

Deja un comentario

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar