Integración Continua
En proyectos de desarrollo de software donde intervienen varios desarrolladores hay necesidad de dividirse el trabajo. Hay muchas estrategias de división de trabajo en un proyecto de software, esta puede ser por componentes, por capas, por conceptos, por requerimientos o casos de uso, etc. El equipo debe definir una estrategia de división y también una estrategia de integración de las partes que cada uno desarrollo. Para la integración, una estrategia posible es esperar a que todos termines y hacer una fase solo de integración, separada del desarrollo. Si bien esta estrategia suena práctica, cada uno trabaja aisladamente y solo se relaciona con los otros para integrar, tiene muchos problemas:
- Descubrir tardíamente problemas de entendimiento de los requerimientos de la arquitectura o los diseños: “los pedazos no pegan”
- Corregir defectos en esta etapa, sobre problemas introducidos en etapas anteriores, son más costos y puede crear nuevos problemas
- La calidad del software es difícil de asegurar
- Las pruebas se ven comprometidas porque aparecen muy tarde en el desarrollo
Todos los problemas anteriores se conocen como "Integration Hell" donde las consecuencias directas es demoras en las entregas como consecuencia de tener que rehacer trabajo y comprometer la calidad del software.
Una alternativa que ha probado ser muy efectiva para resolver los problemas mencionados y que ahora hace parte de la mayoría de las metodologías de desarrollo de software, es la Integración Continua. Como su nombre lo indica, se trata de ir integrando de manera constante a medida que avanza el trabajo de las distintas partes realizado por los distintos desarrolladores.
Es una práctica que nació con la metodología de desarrollo de software ágil llamada eXtreme Programming y fue definido por primera vez por Martin Fowler en el artículo Continuous Integration (10 September 2000: Original version published.)
Las prácticas
Para que este proceso sea posible, el grupo de desarrollo tiene que definir un ambiente de desarrollo robusto muy estandarizado donde para todos sea claro la estructura del proyecto, la arquitectura, los esquemas de nombramiento, el deposito central del código donde se hace la integración, el versionamiento, la construcción de los ejecutables, las pruebas para verificar la calidad, etc.
- Utilizar un depósito para el código central para los artefactos del proyecto
- Automatizar la construcción del ejecutable (el “build”)
- Construir el ejecutable y luego hacer que se pruebe automáticamente
- Cada integrante hace commit cada día
- Cada commit debe producir un nuevo build y un proceso de pruebas
- Probar en un clone del ambiente de producción
- Hacer fácil la obtención de los últimos entregables
- Cada uno puede ver los resultados del último build
- Automatizar el despliegue
Las herramientas
Cada día hay más y más herramientas para los distintos lenguajes y ambientes de desarrollo para dar soporte al proceso. La siguiente imagen, tomada de herramientas integración continua, muestra algunas de ellas. Las que estamos utilizando en nuestros proyectos las explicamos más adelante.
- Git/Github
- Maven
- Jenkis
- Sonar
- Junit
- Arquilian
- Podam
- Nexus