La integración continua (IC) es un proceso en el que software en desarrollo se compila y prueba continuamente a medida que los cambios se envían a un sistema de control de revisiones. El objetivo es identificar los problemas, como los cambios de código que rompen la compilación, las pruebas unitarias rotas y las pruebas funcionales rotas, tan pronto como sea posible después de confirmar un cambio. Al identificar estos problemas antes, se resuelven antes, reduciendo el impacto para todo el equipo. En una metodología de desarrollo ágil como Software , este tipo de información inmediata es fundamental para que el equipo alcance sus objetivos iterativos.
La configuración de un entorno CI consta de varias partes:
- Máquina de construcción dedicada
- Integración continua software
- Construcciones automatizadas y repetibles
- Pruebas unitarias y funcionales automatizadas
CSS utiliza un proceso de integración continua para todos nuestros esfuerzos de desarrollo en software .
Una máquina de fabricación exclusiva e independiente sirve de "sala blanca" para fabricar los productos de software . Esta máquina es un entorno controlado, en el que sólo se realizan nuevas actualizaciones y software cuando nuestro calendario de desarrollo lo permite. Las máquinas de compilación suelen configurarse en un entorno virtualizado, lo que facilita su ampliación y las hace "a prueba de futuro" en caso de que se necesite más capacidad en el futuro.
La segunda parte es el propio servidor de CI. Existen varios sistemas de CI comerciales y en open-source , como Jenkins, Microsoft TFS, Atlassian Bamboo, Cruise Control, Cruise Control.NET y muchos otros. El servidor CI es responsable de gestionar el flujo de trabajo de tu proceso CI. Puede ser activado para construir un producto software manualmente, en una base de tiempo (Nightly Builds), o en una base de cambio mediante la supervisión continua de su Sistema de Control de Revisiones en busca de cambios de los desarrolladores. Los servidores CI ejecutan las pruebas unitarias y analizan los resultados para determinar el estado de una compilación. La mayoría de los servidores CI pueden configurarse para archivar los artefactos de compilación (binarios, instalaciones y símbolos) después de una compilación correcta.
Un tercer componente son las compilaciones automatizadas. Una compilación totalmente automatizada beneficia tanto al proceso CI como al equipo de desarrollo. Lo ideal es que tanto los desarrolladores como el servidor CI utilicen el mismo sistema de compilación automatizada. Un desarrollador sólo debería tener que instalar unos pocos requisitos previos en su equipo (como Visual Studio). El script de compilación debería encargarse de descargar las dependencias necesarias (tanto internas como externas) antes de que comience la compilación del código fuente.
La última parte de una configuración CI (y una buena práctica de desarrollo incluso sin CI) son las pruebas unitarias y funcionales automatizadas. Si bien es bueno saber que un conjunto de cambios en el producto se compilará, es aún mejor saber que no rompen la funcionalidad. Aún mejor que eso es tener esta verificación se lleva a cabo sin ningún tipo de acciones por parte de un desarrollador, liberando a los desarrolladores a permanecer centrado en la construcción de características del producto.
El proceso de IC en acción en el CSS
Nuestro proceso de integración continua se activa cada vez que un desarrollador introduce cambios en nuestro sistema de control de revisiones. Actualmente utilizamos Jenkins como servidor de integración continua. Jenkins tiene sus raíces en el ámbito de Java, pero ahora contiene cientos de plugins para ampliar su funcionalidad. Hasta ahora, ha funcionado muy bien para construir nuestros productos basados en .NET, así como los basados en código nativo. También somos grandes fans del complemento BruceSchneier para Jenkins.
Uno de los muchos datos de Bruce Schneier que aparecen en nuestro sistema de construcción.
Nuestro proceso de construcción existente basado en MSBuild facilitó la configuración de Jenkins. Todo lo que teníamos que hacer era seleccionar la URL de Subversion para el proyecto, y seleccionar nuestro script MSBuild, pasando el nombre de destino que representa la construcción CI completa. Hemos invertido mucho esfuerzo en nuestro sistema de construcción basado en MSBuild. Nuestro objetivo es tener una única plantilla MSBuild que podamos reutilizar para cada producto, lo que permite que nuestras compilaciones sean coherentes y fiables. Nuestro script MSBuild realiza las siguientes tareas:
- Descargar dependencias
- Compilación del código del producto
- Creación y ejecución de proyectos de pruebas unitarias
- La ofuscación se aplica a los resultados de la compilación
- Firma Authenticode de los resultados de la compilación
- Construir la instalación
- Firma Authenticode de la instalación
- Archivos de símbolos enviados a nuestro servidor interno de símbolos
- Archivado en nuestro servidor de archivos interno
Una vez detectado un check-in, el servidor CI descarga automáticamente el código fuente más reciente del producto. Inicia una compilación del código fuente y, si tiene éxito, continúa ejecutando nuestras pruebas, compila los instaladores, firma digitalmente los componentes y publica los artefactos de compilación en nuestro servidor de archivos interno. 10-15 minutos más tarde, tenemos un informe completo sobre la compilación, incluidos los resultados de las pruebas. Por último, el servidor CI nos notifica (a través de una aplicación en la bandeja del sistema o por correo electrónico) si la compilación se ha realizado correctamente o no.
Proceso de integración continua en acción.
Conclusiones
Establecer un buen proceso de CI no es tarea fácil, y requiere más que una cantidad nominal de trabajo para hacerlo bien. Aunque esto conlleva un coste inicial, las organizaciones verán sin duda recompensado su proceso de CI. El proceso de CI descubrirá inmediatamente los fallos de compilación del código fuente y los fallos de las pruebas unitarias, en lugar de dejar que se acumulen y obstaculicen la productividad de todo el equipo. El historial de compilación, incluido el historial de ejecución de pruebas unitarias, se archiva y es accesible a través del portal del servidor de CI. Un proceso CI sólido ayuda a que los desarrolladores sigan escribiendo código, en lugar de trabajar en tareas repetitivas como la ejecución de pruebas unitarias o la construcción manual del producto.
Enlaces
- Jenkins CI - https://jenkins-ci.org
- Plugins Jenkins - https://wiki.jenkins-ci.org/display/JENKINS/Plugins
- Martin Fowler sobre integración continua - https://martinfowler.com/articles/continuousIntegration.html
- Wikipedia: Integración continua - https://en.wikipedia.org/wiki/Continuous_integration
