Integración Continua: ¿Qué es?
Tema: Explicación a grandes rasgos de una plataforma de Integración Continua.
Categoria: Explicación concreta / Integración continua
Tecnologías / Componentes: Subversion, Jenkins, Nexus, Maven
Integración continua es una parte de mejora continua y el punto principal es automatizar el proceso de desarrollo, el cual abarca desde la programación hasta la liberación en producción, sea cual sean los pasos intermedios.
Para poder explicarlo mejor tomaré un ejemplo concreto:
Con integración continua en el área de desarrollo se podrá :
Con integración continua en el área de desarrollo se podrá :
- Un desarrollador inicia un proyecto desde cero y guarda el código en un versionador.
- Los demas desarrolladores podrán accesar a dicho código y pueden codificar todos a la vez y hasta crear otros proyectos o modulos dependientes.
- Mientras cada uno registra sus cambios en el versionador, un servidor de Integración Continua irá bajando cada versión y lo compilará en un ambiente independiente para asegurar que el código funciona en cualquier ambiente sin dependencias de configuración local.
- El mismo servidor hará pruebas unitarias para asegurar que cada versión no ha sufrido una regresión en funcionalidad.
- Después guardará el artefacto (el compilado, ejecutable, jar, war etc) en un repositorio de artefactos como versión SNAPSHOT o EN-DESARROLLO para que otros puedan usarlo.
- En caso que tenga proyectos dependientes, este servidor también obtendrá el código del repositorio de versiones y hará la compilación y pruebas unitarias pero, obviamente, utilizando la versión que se está probando para asegurar que no solo el proyecto funciona sino que no haya provocado errores en sus proyectos o módulos que lo usan.
- Después de verificar las pruebas unitarias, el servidor podrá ejecutar varias tareas escalonadas, tales como pruebas funcionales, siguiendo con pruebas de control de calidad de código, stress, etc.
- Si todos esos pasos han concluido satisfactoriamente podrá hacer la implementación en algún ambiente, por ejemplo UAT o pruebas. Esto implica que ponga el ejecutable en algún contenedor (jboss, tomcat, etc), realice las configuraciones necesarias, configure la base de datos, repositorios, etc para que funcione correctamente en dicho ambiente.
- Después podrá ejecutar pruebas de aceptación sobre la reciente implementación para asegurar que la funcionalidad y requerimientos iniciales estén implementados. Estas pruebas son las mismas que se le entrega a los testers para validar cada caso de uso y escenario, únicamente que estas son automatizadas.
- Si las pruebas son correctas, el servidor podrá hacer nuevamente la implementación pero tal vez ahora en el ambiente de producción.
- Después podrá repetir las pruebas de aceptacion pero ahora con datos reales. Esto se convertiría en Pruebas de Integración ya que estariamos asegurando que la implementación esté correcta y el sistema esté integrado con los demás sistemas como base de datos, mensajeria y hasta redes.
Este ejemplo muestra la capacidad y gran ventaja que ofrece Integración Continua. Lo mas hermoso es que todo esto es automatizado y permite que mientras el desarrollador se dedica a lo suyo, que es codificar e ir avanzando en el proyecto, tras bambalinas se va probando lo que hizo y hasta puede terminar el producción. ¡¡Probablemente se pueden llevar 2 o 3 horas desde que el desarrollador sube algún cambio al repositorio hasta que se encuentre liberado en producción con todo y pruebas!!
¡Que gran ventaja es poder contar con esté framework!
Herramientas que Componen a Integración Continua
Si seguimos el ejemplo previo podemos extraer mínimo 4 componentes :
1. Un compilador de proyectos y administrador de dependencias como Maven. También se les conoce como "build automation"
2. Un controlador de versiones o también conocido como SCM (source control manager o revision control) como Subversion o Git.
3. Un repositorio de artefactos que sirva para separar versiones liberadas y en desarrollo como Nexus o Artifactory.
5. Un servidor de integración continua como Jenkins o Bamboo
6. Una herramienta para pruebas de calidad de código como Sonar.
Prácticamente estos son los componentes mínimos.
En los siguientes artículos iré detallando cada uno de los componentes, sus configuraciones mínimas y sus funcionalidades primarias.
Cabe hacer mención que existe una máquina virtual para virtualbox abierta que se llama Agilebox. Este appliance es gratuito gracias a lebrijo y es una máquina con Ubuntu donde ya vienen todos estos componentes instalados y configurados listo para comenzar a usarse.
Resumen.
Finalmente podemos concluir con las bondades y ventajas que una plataforma de integración continua nos puede dar :
- Automatización de tareas para disminuir error humano.
- Automatización de pruebas para poder hacer análisis y verlo todo en un tablero de control.
- Disminución de responsabilidades extras a los desarrolladores, testers, integradores, etc.
- Establecimiento de métricas y procesos definidos para optimizar y eficientar tiempo y calidad.
- Facilidad para obtener reportes de cada prueba y así poder integrar al usuario en el status de cada proyecto.
- Visibilidad de todos los proyectos y su relación entre varias dependencias.
- Tener un repositorio centralizado tanto de códigos fuentes como de artefactos finales y la capacidad de poderlos dividir entre desarrollo y liberaciones.
- Posibilidad de decrementar el tiempo para liberar a producción cambios y aumentando la calidad.
- emontoya's blog
- Inicie sesión o regístrese para enviar comentarios
Alternativas a AgileBox
Hola, buenas:
Como alternativa a AgileBox tenemos Clinker Virtual Appliance, un producto gratuito de .
Esta VM proporciona subversion + nexus + jenkins + sonar + trac + redmine + sso.
Un saludo
Buen post, más de estos por
Buen post, más de estos por favor.
Me queda una duda. Como se "despliega" ? Permitiendo que el servidor de CI empuje el cambio? O haciendo un branch del instalable y haciendo que el servidor de producción lo jale? Estaría interesante saber como lo hacen en otros lugares.
Donde yo trabajo se genera un instalador y se copia a cada máquina objetivo. De ahí se instala, es un proceso un tanto manual toda vez que no es el servidor de CI el que hace el trabajo completo.
¡Que gran ventaja es poder contar con esté framework! Más bien es una práctica no? Bueno pero se entiende.
Es fácil olvidar lo bueno que es hacer este tipo de cosas, especialmente cuando no se ha tenido que hacer la tarea de "integrar" el trabajo. En otras herramientas en las que he trabajado hay que hacer esta labor una semana, es la "semana de la liberación" y había que tener a todo el equipo pasando uno por uno a la máquina para ver si su trabajo estaba ahí.
Las VM que mencionan están geniales, lo que de verdad no me cabe en la cabeza es porque subversion! Afortunadamente es igual de fácil poner el repositorio en git o en hg.
Por cierto, en Jenkins el cigame esta muy entretenido ( al principio :P ) por cada build o test nuevo exitoso te dan un punto, por cada build o test roto te quitan 10.
Ah y además esta el plugin de ChuckNorris que se enoja cuando se rompe el build
Sobre Subversion
Hola Oscar:
El motivo principal de haber priorizado Subversion es que sigue siendo una opción muy extendida en los entornos profesionales y por tanto, desde el punto de vista de negocio, es interesante darle soporte.
Instalar un SCM no es complicado si va dirigido a un entorno no demasiado exigente pero cuando necesitas soportar un volumen de usuarios importante, alta actividad, etc... las instalaciones por defecto no son recomendables. La instalación de Subversion que proporciona Clinker está optimizada e integrada con Clinker SSO.
Dentro de poco daremos soporte a Git.
Aquí dos entradas, por si te parecen interesante:
Un saludo
Aqui...
Aqui en el proyecto que estoy participando ocupamos un software llamado Team city. La forma de desplegar las diferentes aplicaciones en cuálquier ambiente (test, QA y PROD) es de forma automática esto lo hacemos por medio de scripts de ant, estos scripts tienen por tarea conectarse al servidor, detener el servidor de aplicaciones, limpiar archivos temporales, copiar el artefacto de java (jar, war o ear) y reiniciar el servidor de aplicaciones. También de forma automática cada vez que se suben cambios a SVN se compilan estos nuevos cambios, ademas de ejecutar pruebas unitarias y mandar el código fuente a SONAR para hacer una pequeña audotoria de código. La verdad si es una manera muy buena de trabajar para tener un mínimo en la calidad del codigo y entregables.
Saludos.
@recena :-O Sabes que sería
@recena :-O
Sabes que sería verdaderamente sobresaliente ( y no taaaan dificil de hacer ) migración de 1 click de svn hacia git o hg.
Entiendo que svn sea muy usado pero de verdad, más allá que sea distribuído o no, hacer un branch o un merge con git es mucho, mucho mucho más rápido que en svn y si se quiere integración continua donde varios desarrolladores agreguen cambios constantemente usar svn es una lata. En un proyecto donde el code base es de cerca 1M LOC y el branch se hace en menos de 10 segundos, el merge tambien ( y eso sobre Windows )
Pero de nuevo, entiendo lo de dar soporte a SVN, lo bueno es que ya estan en camino a soportar git :)
Veo que también tienen servicio en la nube, muy bien. Mucho éxito.
Alternativas a AgileBox
excelente, le voy a echar un ojo para comenzar a usarlo tambien!!
Saludos.
Buen post, más de estos por
Hola Oscar,
gracias por tu comentario, y la manera en que nosotros hacemos el deploy es mediante el commit al svn. Está configurado SVN para que le avise a jenkins que inicie el job inicial.
Luego tenemos otro job dentro del mismo pipeline que se encarga del deploy, éste job es parametrizable y se hace cuando en el commit que habíamos echo le ponemos un texto predefinido: por ejemplo:
JENKINS RELEASE: 2.0
Por lo que el job sabrá que debe hacer el deploy con la versión 2.0.
Tengo en mente poner estos tips tambien en otro post dentro del blog. tambien puedes echarle un ojo a mi blog javablog.eliumontoya.com
Hay muy buenos plugins en jenkins, de hecho también quiero usar el de chucknorris e implementar el cigame, super chido!!!
"¡Que gran ventaja es poder contar con esté framework! Más bien es una práctica no? Bueno pero se entiende."
Tienes toda la razon, es una práctica más que un framework; esto si framework lo consideramos como framework de desarrollo.
Si pensamos framework como "marco de trabajo" podría ser válido no?? ... Pero te la compro!! Voy a modificarlo en mi blog.
Saludos!!!
muy bueno...
muy bueno, durante mucho tiempo trabajé integrando código por los viejos métodos, una vez que probé subversión
lamenté no haberlo usado antes.
Reduce muchos errores y sobre todo tiempo.
en mi caso ha sido el subversio que está en el repo de debian + netbeans 6.5.1 (el último que vale la pena, y que alguien le pregunte a oracle por qué, jajaja)
saludos