IntegracionContinua. Departamento de Sistemas y Computación Universidad de los Andes, Bogotá

Transcripción

1 IntegracionContinua Departamento de Sistemas y Computación Universidad de los Andes, Bogotá

2 Referencias usintegration.html (10 September 2000: Original version published.)

3 Agenda Contexto Problemas que intenta resolver Detalle del proceso y herramientas

4 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

5 Contexto Proceso de integración puede ser muy largo e impredecible: Cuándo termina? Cuánto falta? Cuál es la calidad del resultado?

6 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

7 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

8 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.

9 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

10 Imagen Tomada de:

11 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

12 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

13 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 Herramientas CVS, SVN, ClearCase, Control de versiones de Team Foundation (TFVC), Git, make, ant, gradle, Nmaven, nuget, maven,.. 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,..

14 Build makers: maven, ant Git, SVN, CVS IDE: Netbeans, Eclipse, Visual Studio Hudson, Sonar, BugTracker: Jira, mantis Build makers: maven, ant Deposito de artefactos: Nexus, Artifact,.. Server de IC: Hudson, jenkis, Scripts sql, podam Sonar, jcoverage Métricas de código: Sonar, parasoft, jasca, Tests: junit, arquilian, selenium, mockito, podam, rest-assured,

15 Ambiente Local Build makers: maven, ant Deposito de artefactos: Nexus, Artifact,.. Tests: junit, arquilian, selenium, mockito, podam, rest-assured,

16 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

17 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

18 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: , IRC, Jabber, SMS, Twitter, RSS

19 Instalación Un war en un servidor web (Jetty, tomcat,..)

20 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

21