IntegracionContinua - Universidad de los Andes

IntegracionContinua
Departamento de Sistemas y Computación
Universidad de los Andes, Bogotá
Referencias

http://www.martinfowler.com/articles/continuo
usIntegration.html (10 September
2000: Original version published.)
Agenda



Contexto
Problemas que intenta resolver
Detalle del proceso y herramientas
Contexto




Proyectos grandes (cientos, miles, millones,
.. De líneas de código)
Grupos de trabajo de varios desarrolladores
(5, 10, 30, …)
Alta presión
Cambios constantes
Contexto

Proceso de integración puede ser muy largo
e impredecible:



Cuándo termina?
Cuánto falta?
Cuál es la calidad del resultado?
Problemas que intenta resolver

Si el proceso de integración es una etapa
separada en el desarrollo:




Se puede descubrir tardíamente problemas de
entendimiento de los requerimientos, la
arquitectura, …
Correcciones en esta etapa, sobre problemas
introducidos en etapas anteriores, son más costos
de corregir 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
Los comienzos …


Es una práctica que nació con eXtreme
Programming
Inicialmente se quería usar en combinación
con las pruebas unitarias automáticas:


Antes de hacer commit sobre la rama principal del
proyecto, todas las pruebas deberían ser exitosas
El objetivo es evitar que el trabajo de algún “enprogreso” desarrollador dañara lo de otro
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. …”
http://martinfowler.com/articles/continuousIntegration.html
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. Many teams
find that this approach leads to significantly reduced
integration problems and allows a team to develop
cohesive software more rapidly.” Martin Fowler
http://martinfowler.com/articles/continuousIntegration.html
Imagen Tomada de: http://blog.juliopari.com/integracion-continua-en-proyectos-agiles-de-software/
Principios





Utilizar un depósito para el código del proyecto
Automatizar (el “build”) la construcción del
ejecutable
Hacer un build que se pruebe de forma
automática
Cada integrante hace commit cada día
Cada commit debe producir un nuevo build y
un proceso de pruebas
Principios




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
Principios
Herramientas
Utilizar un depósito para el código del
proyecto
CVS, SVN, ClearCase, Control de
versiones de Team Foundation (TFVC),
Git,…
Automatizar (el “build”) la construcción del make, ant, gradle, Nmaven, nuget,
ejecutable
maven,..
Hacer un build que se pruebe de forma
automática
Arquilian, glassfish embebido, ..
Cada commit debe producir un nuevo
build y un proceso de pruebas
Hudson, Jenkis, Team Foundation Server
Cada uno puede ver los resultados del
último build
Hudson, Sonar, Jenkis, ..
IDE: Netbeans, Eclipse, Visual Studio
Build
makers:
maven, ant
Hudson,
Sonar,
BugTracker:
Jira, mantis
Git, SVN, CVS
Build
makers:
maven, ant
Deposito de
artefactos:
Nexus,
Artifact, ..
Server de
IC:
Hudson,
jenkis,…
Tests: junit, arquilian, selenium, mockito,
Métricas de código:
Sonar, parasoft, jasca,… podam, rest-assured,…
Scripts sql,
podam
Sonar,
jcoverage
Ambiente Local
Build
makers:
maven, ant
Deposito de
artefactos:
Nexus,
Artifact, ..
Tests: junit, arquilian, selenium, mockito,
podam, rest-assured,…
Hudson


Monitorea la ejecución d e tareas repetitivas,
como hacer un build. Las tareas se programan
para ser ejecutadas en un afecha y hora (cron)
Las tareas principales son:



Construir (build) un proyecto a partir de las fuentes de
un depósito de versiones
Reportar los resultados
Es una herramienta extensible a través de plugins
Hudson


Monitorea la ejecución d e tareas repetitivas,
como hacer un build. Las tareas se programan
para ser ejecutadas en un afecha y hora (cron)
Las tareas principales son:



Construir (build) un proyecto a partir de las fuentes de
un depósito de versiones
Reportar los resultados
Es una herramienta extensible a través de plugins
Algunos plug-ins disponibles









SCM vendors: Git, CVS, SVN, Perforce, Mercurial, Team
Foundation
Build tools: Ant, maven, gradle, MSBuild, Nant, Rake
Unit Testing frameworks: JUnit, NUnit, Selenium, CppUnit, TestNg,
XUnit
Code Coverage tools: Clover, Cobertura, Emma, Serenity, Sonar,
NCover, Jacoco
Code Analysis Tools: Checkstyle, PMD, Dry, Findbugs, Warnings,
CCM, Violations
Security Tools: LDAP, Active Directory, Crowd, OpenID
Applications servers: Weblogic, Glassfish, Tomcat, JBoss, IIS,
JRebel
Virtual Environment: EC2, Virtual Box, VmWare, JCloud
Social communication: E-mail, IRC, Jabber, SMS, Twitter, RSS
Instalación

Un war en un servidor web (Jetty, tomcat, ..)
Usar Hudson

Crear una tarea para ser ejecutada
automáticamente:






Sacar las fuentes de un depósito de versiones
Cada cuánto se va a ejecutar
Configurar la ejecución de maven
Configurar Sonar para que saque los reportes
Forma en que va a informar las fallas
Conserva la historia de las ejecuciones