Integración Continua – Introducción

Jenkins

Introducción

El proceso de integración continua, como casi todo lo que está relacionado con software, fue propuesto por Martin Fowler y consiste en integrar constante y automáticamente nuestro código para detectar fallos lo más pronto posible. En un inicio fue adaptado por los seguidores de Xtreme Programming (XP) por eso se menciona que es una parte importante de un equipo Ágil ya que ayuda a reforzar y cumplir las ideas propuestas por el desarrollo ágil.

Integración continua

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible – Martin Fowler 

En su forma más básica la integración continua involucra solo una herramienta que debe monitorear el repositorio del código fuente para detectar algún cambio o en su defecto ejecutarse bajo cierta programación establecida, si un cambio es detectado automáticamente esta herramienta debe descargar la última versión del código, compilar el código y ejecutar las pruebas. En caso de error la herramienta debe notificar a los desarrolladores que error ha ocurrido para que lo solucionen inmediatamente. En su forma completa la integración continua puede ayudarnos a monitorear automáticamente la calidad de código, las métricas de code coverage y puede acelerar la entrega automatizando el proceso de despliegue.

¿Qué logramos aplicando la integración continua?

Al aplicar el proceso integración continua nuestro sistema se vuelve:

• Integrado (Integrated): Todos los cambios hasta el momento de la ejecución son combinados en el proyecto.
• Construido (Built): El código es compilado y se genera un ejecutable o un paquete.
• Probado (Tested): Las suites de pruebas automatizadas son ejecutadas.
• Archivado (Archived): Versionados y almacenados de modo que pueden ser distribuidos si se desea.
• Desplegado (Deployed): Cargados en un ambiente donde los desarrolladores puedan interactuar con el sistema.

Continuous integration workflow – Fuente: SEI

Beneficios

Luego de aplicar todos estos pasos obtenemos los siguientes beneficios:

• Detección inmediata de bugs, luego de ejecutar las suits de pruebas.
• Tiempos bajos o nulos de integración de código, ya que en todo el proceso se ha venido realizado esta tarea.
• Contamos con un sistema que puede ser desplegado en cualquier momento.
• Registro del historial de compilación del sistema y otros tipos de reportes.

Practicas recomendadas:

Para ejecutar con éxito el proceso de integración continua se recomienda que se sigan las siguientes prácticas:

• Mantener el código en un repositorio:
  • Esta práctica recomienda el uso de un controlador de versiones, todos los artefactos requeridos para la compilación deben encontrarse en el repositorio.
• Automatizar las compilaciones:
  • Indica que un simple comando tiene la capacidad de construir o compilar el sistema.
• Automatizar las pruebas:
  • Luego de que el código es compilado se deben ejecutar todos los test para validar que el sistema se comporta como esperaban los desarrolladores.
• Hacer commits diarios:
  • Hacer commits frecuentes ayuda a que se reduzcan el número de conflictos hechos por los cambios del equipo.
• Cada commit debe compilar:
  • El sistema debe compilar el cambio hecho para con la versión actual para verificar que el cambio se integre correctamente.
• Mantener la compilación rápida:
  • La compilación debe ser rápida, si existe un problema con la integración es identificada de rápidamente.
• Realizar pruebas en un entorno parecido al de producción:
  • Contar con un ambiente parecido al de producción nos ayudara a detectar fallas en el sistema antes que se despliegue en producción. Sin embargo, tener una réplica de producción tiene un costo.
• Facilita la entrega de los últimos entregarles:
  • Tener las compilaciones listas para ejecutar reduce el tiempo de re trabajo necesario para generar el entregable de una característica del sistema que no cumplía con el requerimiento.
• Todos pueden ver el resultado de la compilación:
  • Debe ser fácil ver cuando una compilación fallo, si ese es el caso también se debe ver los detalles del cambio que origino ese error.
• Automatizar despliegues:
  • Después de terminar la compilación del código es necesario desplegar el compilado a un ambiente de pruebas o producción, dependiendo del caso, esto se puede hacer gracias a la ayuda de automatización de scripts o plugins que se encargan de esta actividad.

Herramientas de integración continua

Para empezar con el proceso de integración continua podemos usar las siguientes herramientas:

• Hudson
• Jenkins
• Go
• TeamCity
• Team Foundation Build
• Cruise Control
• Bamboo

¿Cómo empezar con la integración continua?

Para poder introducir de a poco la integración continua en una empresa sin morir en el intento se pueden seguir las siguientes fases:

• Fase 1: No se cuenta con un servidor de compilación
  • En esta fase la integración se realiza manualmente usando un IDE o un script de compilación. El código fuente puede estar almacenado en un repositorio, sin embargo los desarrolladores no hacen commits frecuentes. En esta fase la integración se realiza poco antes de hacer la entrega del producto, la cual por lo general es muy costosa y se sufre demasiado.
• Fase 2: Compilaciones nocturnas
  • En esta fase el equipo ya cuenta con un servidor de compilación de algún tipo y las compilaciones son programadas para que se realicen en la noche. En esta fase solo se compila el código y no existen pruebas automatizadas o si las hay no se ejecutan correctamente. También, en esta fase ya se realizan commits frecuentes por lo menos una vez al día, si se sube un cambio que entra en conflicto con otro el servidor de compilación debe alertar del problema ocurrido en la mañana. Sin embargo, el equipo solo usa el servidor de compilación solo como algo informativo ya que no tienen la obligación de corregir el conflicto de inmediato.
• Fase 3: Compilaciones nocturnas y ejecución de pruebas sencillas
  • El equipo ya cuenta con una suite de pruebas, la compilación se dispara en cada commit que se realiza y se pueden ver los cambios hechos en cada commit. En la compilación se ejecutan las pruebas unitarias y/o de integración, en caso de ocurrir algún problema se envía de inmediato una notificación para que el equipo lo resuelva.
• Fase 4: Introducir métricas
  • En esta fase se ejecutan automáticamente las métricas de code coverage y code quality para ayudar a evaluar la calidad del desarrollo y la efectividad de las pruebas. También, el equipo cuenta con un dashboard donde pueden ver el estado del proyecto en términos de calidad.
• Fase 5: Mejorar el suite de pruebas
  • Los beneficios de la integración continua están muy relacionados con las prácticas de pruebas robustas. En esta fase el equipo puede practicar Test Driven Development (TDD), pero ahora el código no solo es compilado y testeado sino que también es desplegado a un servidor de aplicaciones para realizar pruebas de rendimiento y de caja negra.
• Fase 6: Automatizar las pruebas de aceptación y el despliegue
  • En esta fase el equipo puede practicar Behavior Dirven Development (BDD), ahora las pruebas automatizadas usan herramientas que publican los resultados de las pruebas de aceptación para que todos los interesados las puedan conocer. La aplicación es desplegada en el ambiente de QA para que pueda ser probada por el equipo de calidad por cada cambio hecho o en las noches. Finalmente, ahora se puede sacar una copia del release en caso ocurra un error y se necesite regresar a una versión anterior.
• Fase 7: Despliegue continuo
  • Luego de haber automatizado las pruebas unitarias, de integración y de aceptación, y todo las demás practicas realizadas en las fases anteriores, es momento que el equipo automatice los despliegues a producción

La transición entre fases no siempre es la misma esto es algo aproximado, sin embargo esto sirve para darnos una idea de cómo implementar una estrategia de integración continua.

Demo: Implementando un proceso básico de integración continua desde cero

A continuación veremos una demo de un proceso de integración continua básico que debe ayudar a entender mejor la idea detrás de esta práctica muy recomendada.

Paso 1: Descargar código del TFS

Creamos el archivo IntegracionContinua.bat en C: y agregamos el siguiente contenido.

Nota: Usar una cuenta y url de TFS a la que tengan acceso. Reemplazar el valor de la variable UrlTFS.

SET RutaTFS=C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\
SET UrlTFS=https://demo.visualstudio.com/DefaultCollection/

"%RutaTFS%tf.exe" workspaces -format:brief -server:%UrlTFS% /demo@outlook.com
"%RutaTFS%tf.exe" workspace /new LocalRepositorio /server:%UrlTFS% /noprompt
"%RutaTFS%tf.exe" workfold /workspace:LocalRepositorio $/Repositorio/PruebaConcepto/Code2Read.WebCI D:\Temp\Build\Code2Read.WebCI
"%RutaTFS%tf.exe" workfold /unmap /workspace:LocalRepositorio $/
cd "D:\Temp\Build\Code2Read.WebCI"
D:
"%RutaTFS%tf.exe" workspaces /collection:%UrlTFS%
IF EXIST TetsResults.trx del /F TetsResults.trx
"%RutaTFS%tf.exe" get /recursive /noprompt /overwrite
"%RutaTFS%tf.exe" workspace /delete LocalRepositorio /noprompt

Paso 2: Compilar el código

Agregamos las siguientes líneas al archivo IntegracionContinua.bat para compilar el código descargado del TFS.

SET RutaMsBuild=C:\Windows\Microsoft.NET\Framework64\v4.0.30319\
"%RutaMsBuild%msbuild.exe" Code2Read.WebCI.sln

Paso 3: Ejecutar las pruebas unitarias

Ahora agregamos estas líneas para ejecutar las pruebas unitarias que se encuentran en la solución.

SET RutaMsTest=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\
"%RutaMsTest%mstest.exe"/noisolation /testcontainer:Code2Read.WebCI.Tests\bin\Debug\Code2Read.WebCI.Tests.dll /resultsfile:TetsResults.trx

Paso 4: Ejecutar análisis de código

A continuación ejecutaremos el analizador del código del Visual Studio Code Metrics.

Referencia: Visual Studio Code Metrics ¿Cómo aseguras la calidad de tu código?

SET RutaMsCodeMetrics=C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop\
"%RutaMsCodeMetrics%metrics.exe" /f:Code2Read.WebCI/bin/Code2Read.WebCI.dll /o:MetricsResults.xml

Paso 5: Desplegar el compilado

Como último pasa agregamos la líneas de comando para desplegar el código en una carpeta compartida.

Nota: Reemplazar el valor de la variable RutaDespliegue.

SET RutaDespliegue=C:\inetpub\wwwroot
"%RutaMsBuild%msbuild.exe" "Code2Read.WebCI/Code2Read.WebCI.csproj" /p:Platform=AnyCPU /p:RunCodeAnalysis=False;Configuration=Release;DeployOnBuild=true;deployTarget=Package;_PackageTempDir="%RutaDespliegue%";AutoParameterizationWebConfigConnectionStrings=false

Paso 6: Programar la ejecución de la tarea

Finalmente, ahora solo queda programar el archivo IntegracionContinua.bat para que se ejecute todas los días a la media noche.

• Ir a panel de control -> Herramientas administrativas -> Programador de tareas -> Crear tarea básica.
• Agregamos el nombre de la tarea -> Ejecución diaria -> Repetir cada un día -> Iniciar un programa -> seleccionamos el archivo IntegracionContinua.bat y finalizamos.

Paso 7: Verificar la ejecución de los pasos

• Buscamos la tarea y seleccionamos la opción ejecutar.

Programación de tarea CI

• Al terminar la ejecución vamos a la carpeta que hemos configurado para que se descargue el código y veremos que han aparecido los archivos: MetricsResults.xml y TestResult.trx.
• Para terminar vamos a la carpeta que hemos configurado el despliegue y vemos que se encuentra el sitio web compilado.

Para descargar el código de ejemplo y el archivo bat pueden hacerlo desde acá.

Referencias:

• Wikipedia – Integración continua
• Martin Fowler – Continuous integration

Metal Tip:

Este artículo lo escribí escuchando la canción I cum blood de la banda Cannibal Corpse de Usa, les comparto el enlace.

Happy coding and Stay Heavy lml