Integra C I On Continua

“capacitación y guía para el desarrollo de software”
Integración Continua
Integración Continua 1
DEFINICIONES ............................................................................................................................................................................. 3
BUILD ........................................................................................................................................................................................... 3
INTEGRACIÓN CONTINUA ..................................................................................................................................................................... 3
ESCENARIO .................................................................................................................................................................................. 4
NODOS DEL AMBIENTE DE DESARROLLO .................................................................................................................................................. 4
FORMA DE TRABAJO ........................................................................................................................................................................... 5
Pasos ....................................................................................................................................................................................... 5
COMPONENTES POR TAREA DEL AMBIENTE DE DESARROLLO ............................................................................................................................. 6
COMPONENTES POR NODO DEL AMBIENTE DE DESARROLLO .............................................................................................................................. 7
REDUCIR LOS RIESGOS ....................................................................................................................................................................... 8
BUENAS PRÁCTICAS ........................................................................................................................................................................ 10
HERRAMIENTAS .............................................................................................................................................................................. 11
SCM - Escenario de trabajo de SCM ........................................................................................................................................... 11
Patrones de Administración de “Software Configuration Management” ............................................................................................ 12
MAVEN ........................................................................................................................................................................................ 15
Ciclos de vida de un proyecto Maven .......................................................................................................................................... 16
Lifecycle Reference .................................................................................................................................................................. 18
Built-in Lifecycle Bindings ......................................................................................................................................................... 20
CRUISECONTROL ............................................................................................................................................................................ 25
CONFIGURACIÓN ................................................................................................................................................................................ 26
REFERENCIAS ............................................................................................................................................................................. 31
Definiciones
Build
Un “build” es el producto generado por la realización de las tareas de compilación, prueba, inspección e instalación. Realizar un “build” tiene
como resultado situar el código todo junto en un ambiente donde funciona de una manera cohesiva.
Integración Continua
Estratégicamente hacerlo con cada cambio !!!
¿Por Qué?
Para responder esta pregunta hay que entender cuál es el objetivo principal de un grupo de desarrollo de software y cuáles son los riesgos
para lograrlo.
Escenario
Nodos del Ambiente de Desarrollo
Forma de trabajo
Pasos
1. Un desarrollador realiza un commit (cambios) sobre el SCM server mientras el administrador de CI lo consulta por cambios con una
frecuencia determinada.
2. Después del commit el administrador de CI detecta el cambio, toma del repositorio las últimas versiones y ejecuta los scripts que
integran todo el software
3. El administrador de CI informa por mail acerca de los resultados a los miembros del grupo de desarrollo de los resultados del build
4. El administrador continua consultando al repositorio con la frecuencia determinada
Componentes por tarea del ambiente de desarrollo

cd ICSoftw are
Tomcat 5.5 SVN 1.4.2 CruiseControl 2.7.3
Checkstyle
PMD/CPD
Eclipse Ganymede Apache Maven 2.0.9

JDepent
Clover
JUnit 3.8.1 SVN Reportes de Cambios
JavaDoc
Apache Ant 1.7.1
Doxygen
Referencias
JIRA SE 3.13
Compilación y Admin. Repositorio
Centralización de Info
Integración Contínua Enterprise Architecture 6.1

Pruebas y Rev isiones
Publicación
Componentes por nodo del ambiente de desarrollo

cd HerramientasXNodo
Tomcat 5.5 SVN 1.4.2 CruiseControl 2.7.3
Checkstyle
PMD/CPD
Eclipse Ganymede Apache Maven 2.0.9

JDepent
Clover
JUnit 3.8.1 SVN Reportes de Cambios
JavaDoc
Apache Ant 1.7.1
Referencias Doxygen
Serv idores
JIRA SE 3.13
Serv idores y Estaciones de
Trabaj o
Enterprise Architecture 6.1
Estaciones de Trabaj o
Reducir los riesgos

Riesgo Causas Consecuencias Escenarios Sugerencias Solución
Pérdida de software • Proceso de • Componentes • En mi PC • Eliminar Automatiz
instalable build manual repetidos Problemas funciona pero dependencias ar el
• Falta de test de integración de en servidor NO del IDE y proceso de
rápidos y cbios porque faltaba proceso de build con
repetibles • Integración el commit del build Maven
• Falta de excesivamente larga último cbio • Scripts en
pruebas en un • Desconfianza en • DB creada por SCM
ambiente limpio grupo Desa DBA en ejecutados
• Mala ubicación de ambiente de en proceso
archivos de DESA y ahora de build
configuración no está • Test de
• Deployment integración
manual tedioso Proceso de
deployment
automático
Detección tardía de Pruebas manuales Introducción de error • En este release • Hacer los test Automatiz
errores nuevo al corregir uno apareció un repetibles y ar el
existente error corregido fáciles de proceso de
hace dos ejecutar pruebas
meses • Herramienta con xUnit y
• Tenemos de chequeo Clover
varios test y de cobertura
corren OK, son de test
suficientes?
Pobre visibilidad del Comunicación • Gran esfuerzo de • Falló test por • Mails Automatiz
proyecto manual coordinación tu último cbio automáticos ar
• No leíste el • Generar comunicaci
reporte de documentaci ón con
cbios al diseño ón Cruise
• Necesitamos actualizada Control,
Riesgo Causas Consecuencias Escenarios Sugerencias Solución

UML pero Maven y
actualizado Doxygen
Baja calidad del Código • Código difícil de • Nuevos • Definir Automatiz

software potencialmente mantener y cambiar programadores estándares y ar
peligroso cumplen chequearlos revisiones
No se cumplen estándares? • Revisar con
estándares • Refactorización Diseño y CheckStyle
definidos afectó la Código , PMD y
arquitectura? JDepent
• Cbios apurados
introdujeron
código
duplicado?
Buenas prácticas
cd Prácticas
Buenas prácticas de trabajo con SCM Construya binarios con

cada cambio
(software configuration management)
Haga commit con NO haga commit de código Corrija los errores que
frecuencia que no funciona rompieron el buid
inmediatamente
Escriba tests unitarios TODOS los test y revisiones Ejecute builds privados
automáticos deben ejecutar OK
NO tome código del

repositorio que no funciona
Herramientas
SCM - Escenario de trabajo de SCM
Patrones de Administración de “Software Configuration Management”

Gráfico extraído de Software Configuration Management Patterns, Berczuk, Appleton, 2008.
cd Prácticas
Buenas prácticas de trabajo de build Automatice el proceso de

build
(compilación y linkeo)
Ejecute comandos simples Separe scripts de build del Centralice todos los
de build IDE componentes del software
en un repositorio
Cree una estructura de Fail builds rápidamente Build para cualquier

directorios consistente ambiente
Use una computadora Use un CI server Ejecute builds rápidos

dedicada a la integración
Mantenga la historia de los

builds
cd Prácticas
Buenas prácticas de trabajo de build Automatice la integración

de DB
(integración de la DB)
Utilice una copia privada de Utilice el repositorio para Asigne capacidad a los
la DB compartir los componentes DESA para modificar la DB
de la DB
Maven
cd mav en
Repositories (Local y
Remoto)
Plugins Mav en Build System «file»

Producto.j ar
POM (Proj ect Obj ect Model)
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" my-app

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> |-- pom.xml
<modelVersion>4.0.0</modelVersion> `-- src
<groupId>com.mycompany.app</groupId> |-- main
<artifactId>my-app</artifactId> | `-- java
<packaging>jar</packaging> | `-- com
<version>1.0-SNAPSHOT</version> | `-- mycompany
<name>Maven Quick Start Archetype</name> | `-- app
<url>http://maven.apache.org</url> | `-- App.java
<dependencies> `-- test
<dependency> `-- java
<groupId>junit</groupId> `-- com
<artifactId>junit</artifactId> `-- mycompany
<version>3.8.1</version> `-- app
<scope>test</scope> `-- AppTest.java
</dependency>
</dependencies>
</project>
cd mav en2
Local Repository Remote Repository
junit / jars / junit3.8.1.jar

junit / jars / junit3.8.1.jar
POM Project
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
Maven
settings.xml
Repositorio local: proxy contra el repositorio público (central) y lugar de instalación de los productos generados en el desarrollo. Cache local
para todo el software que solo UNA VEZ será bajado al local para todos los proyectos de la organización.
SNAPSHOT: dependencias chequeadas por Maven para utilizar la última versión (dependencias que cambian mucho u otros proyectos en
desarrollo)
Ciclos de vida de un proyecto Maven

• default: administra hasta el deployment
• clean: administra las tareas de reseteo del build anterior
• site: administra la creación del sitio de publicación del proyecto
cd Mav enLifeCicle
Fases del ciclo de vida default de Maven
1 - validate
2 - compile
3 - test
4 - package
5 - integration-test
6 - verify
7 - install
8 - deploy
Invocación sin objetivos -> mvn deploy

Invocación con objetivos -> mvn clean dependency:copy-dependencies package
Lifecycle Reference
The following lists all build phases of the default, clean and site lifecycle, which are executed in the order given up to the point of the one specified.
Clean Lifecycle
pre-clean executes processes needed prior to the actual project cleaning
clean remove all files generated by the previous build
post-clean executes processes needed to finalize the project cleaning
Default Lifecycle
validate Validate the project is correct and all necessary information is available.
initialize Initialize build state, e.g. set properties or create directories.
generate-sources Generate any source code for inclusion in compilation.
process-sources Process the source code, for example to filter any values.
generate-resources Generate resources for inclusion in the package.
process-resources Copy and process the resources into the destination directory, ready for packaging.
compile Compile the source code of the project.
process-classes Post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
generate-test- Generate any test source code for inclusion in compilation.

sources
process-test-sources Process the test source code, for example to filter any values.
generate-test- Create resources for testing.

resources
process-test- Copy and process the resources into the test destination directory.
resources
test-compile compile the test source code into the test destination directory
process-test-classes Post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and
above.
test Run tests using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
prepare-package Perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed
version of the package. (Maven 2.1 and above)
package Take the compiled code and package it in its distributable format, such as a JAR.
pre-integration-test Perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test Process and deploy the package if necessary into an environment where integration tests can be run.
post-integration- Perform actions required after integration tests have been executed. This may including cleaning up the environment.
test
verify Run any checks to verify the package is valid and meets quality criteria.
install Install the package into the local repository, for use as a dependency in other projects locally.
deploy Done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and
projects.
Site Lifecycle
pre-site executes processes needed prior to the actual project site generation
site generates the project's site documentation
post-site executes processes needed to finalize the site generation, and to prepare for site deployment
site-deploy deploys the generated site documentation to the specified web server
Built-in Lifecycle Bindings
Some phases have goals binded to them by default. And for the default lifecycle, these bindings depend on the packaging value. Here are some of the goal-
to-build-phase bindings.
Clean Lifecycle Bindings

clean clean:clean
Default Lifecycle Bindings - Packaging ejb / ejb3 / jar / par / rar / war
process-resources resources:resources
compile compiler:compile
process-test-resources resources:testResources
test-compile compiler:testCompile
test surefire:test
package ejb:ejb or ejb3:ejb3 or jar:jar or par:par or rar:rar or war:war
install install:install
deploy deploy:deploy
Default Lifecycle Bindings - Packaging ear

generate-resources ear:generateApplicationXml
package ear:ear
Default Lifecycle Bindings - Packaging maven-plugin

generate-resources plugin:descriptor
compile compiler:compile
process-test-resources resources:testResources
test-compile compiler:testCompile
test surefire:test
package jar:jar and plugin:addPluginArtifactMetadata
install install:install and plugin:updateRegistry
Default Lifecycle Bindings - Packaging pom

package site:attach-descriptor
Site Lifecycle Bindings

site site:site
site-deploy site:deploy
cd Prácticas
Buenas prácticas de trabajo de pruebas(unitarias, de Automatice los test

unitarios
componentes, de sistema, funcionales)
Automatice los test de Automatice los test de Automatice los test

componentes sistema funcionales
Categorice los tests Ejecute primero los test Escirba tests para
más rápidos reproducir errores
Haga repetibles a los test Limite casos de test a un

de componentes componente
cd Prácticas
Buenas prácticas de trabajo de revisiones (diseño, Reduzca la complejidad del

código
código y cubrimiento)
Revise el diseño en forma Mantenga estándares Reduzca código duplicado

continua organizaciones mediante
QA
Controle el cubrimiento de
las pruebas y revisiones
cd Prácticas
Buenas prácticas de trabajo con releases Instale el software en

tiempo y lugar
(software configuration management + build)
Marque en el repositorio los Trabaje en un ambiente Nombre cada release

componentes incluidos limpio
Ejecute TODOS los tests Genere reportes del Genere capacidad para
proceso de build e volver atrás releases
instalación
cd Prácticas
Utilice mecanismos de
Buenas prácticas de trabajo de integración comunicación para generar
continua (integración continua) realimentación
CruiseControl
Gráfico extraído del sitio oficial de CruiseControl
Configuración
<cruisecontrol>
<!—Configuración del Repositorio -->
<property name="svn.repository" value="file:///C:/Users/gpantaleo/trabajo/SVN"/>
<property name="svn.portal.project" value="${svn.repository}/AnalisisValidacion"/>
<!—Configuración específica de compilación -->
<property name="maven.home" value= "c:/Users/gpantaleo/trabajo/Maven/apache-maven-2.0.9"/>
<property name="ant.home" value="C:/ant"/>
<!—Configuraciones específicas del Cruise Control Scheduler -->
<property name="schedule.interval" value="300"/>
<property name="quiet.period" value="30"/>
<plugin name="m2projectCI" classname="net.sourceforge.cruisecontrol.ProjectConfig" buildafterfailed="false">
<log> 
<merge dir="projects/AnalisisValidacion/trunk/${project.name}" pattern="TEST-*.xml" />
</log>
</plugin>

<m2projectCI name="codigo">

<plugin name="svn" classname="net.sourceforge.cruisecontrol.sourcecontrols.SVN"/>
<plugin name="svnbootstrapper" classname="net.sourceforge.cruisecontrol.bootstrappers.SVNBootstrapper"/>
<!—Log de estados del build al file system. -->
<listeners>
<currentbuildstatuslistener file="logs/${project.name}/status.txt"/>
</listeners>
<!— Observador (boostrap) de cambios en Subversion
<bootstrappers>
<svnbootstrapper LocalWorkingCopy="projects/AnalisisValidacion" />
</bootstrappers>
<!—Conjunto de elementos indicativos de cambio en la instalación de CruiseControl.<modificationset> puede contener múltiple elementos, críticos, los
cuales serán chequeados en lugar de chequear todos los files de un proyecto. -->
<modificationset quietperiod="${quiet.period}">
<svn localWorkingcopy="projects/AnalisisValidacion" repositoryLocation="${svn.portal.project}" useLocalRevision="true"/>
<maven2snapshotdependency pomfile="projects/AnalisisValidacion/trunk/codigo/pom.xml"/>
<!—cualquier cbio. en estos files dispararán un build -->
<filesystem folder="projects/AnalisisValidacion/trunk/codigo/src"/>
<buildstatus logdir="logs/codigo" />
</modificationset>
<!—Acciones principales: 1) se copian los cambios del repositorio a los directorios locales del proyecto, 2) se invoca a Maven para realizar el build -->
<schedule interval="${schedule.interval}">
<composite>
<ant anthome="${ant.home}" buildfile="projects/AnalisisValidacion/svn-build.xml"/>
<maven2 mvnhome="${maven.home}" pomfile="projects/AnalisisValidacion/trunk/codigo/pom.xml" goal="clean | deploy | site:site site:deploy" />
<maven2 mvnhome="${maven.home}" pomfile="projects/AnalisisValidacion/trunk/codigo/pom.xml"
goal="clover2:instrument clover2:aggregate clover2:clover"/>
</composite>
</schedule>
</m2projectCI>
</cruisecontrol>
Referencias
Continuous Integration: Improving Software Quality and Reducing Risk, Paul M. Duvall with Andrew Glover
and Steve Matyas, 2008.
xUnit Test Patterns: Refactoring Test Code, Gerard Meszaros, Addison-Wesley, 2007.
Software Configuration Management Patterns: Effective Teamwork, Practical Integration (Software Patterns
Series),
Stephen P. Berczuk (Author), et al, 2008.

Integra C I On Continua

Cargado por

Copyright:

Formatos disponibles

Integra C I On Continua

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Integra C I On Continua

Cargado por

Copyright:

Formatos disponibles

“capacitación y guía para el desarrollo de software”

Componentes por tarea del ambiente de desarrollo

Tomcat 5.5 SVN 1.4.2 CruiseControl 2.7.3

Eclipse Ganymede Apache Maven 2.0.9

JUnit 3.8.1 SVN Reportes de Cambios

Integración Contínua Enterprise Architecture 6.1

Componentes por nodo del ambiente de desarrollo

Tomcat 5.5 SVN 1.4.2 CruiseControl 2.7.3

Eclipse Ganymede Apache Maven 2.0.9

JUnit 3.8.1 SVN Reportes de Cambios

Reducir los riesgos

Riesgo Causas Consecuencias Escenarios Sugerencias Solución

Baja calidad del Código • Código difícil de • Nuevos • Definir Automatiz

Buenas prácticas de trabajo con SCM Construya binarios con

NO tome código del

Patrones de Administración de “Software Configuration Management”

Buenas prácticas de trabajo de build Automatice el proceso de

Cree una estructura de Fail builds rápidamente Build para cualquier

Use una computadora Use un CI server Ejecute builds rápidos

Mantenga la historia de los

Buenas prácticas de trabajo de build Automatice la integración

Plugins Mav en Build System «file»

POM (Proj ect Obj ect Model)

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" my-app

Local Repository Remote Repository

junit / jars / junit3.8.1.jar

Ciclos de vida de un proyecto Maven

Fases del ciclo de vida default de Maven

Invocación sin objetivos -> mvn deploy

pre-clean executes processes needed prior to the actual project cleaning

clean remove all files generated by the previous build

post-clean executes processes needed to finalize the project cleaning

initialize Initialize build state, e.g. set properties or create directories.

generate-sources Generate any source code for inclusion in compilation.

generate-resources Generate resources for inclusion in the package.

compile Compile the source code of the project.

generate-test- Generate any test source code for inclusion in compilation.

generate-test- Create resources for testing.

site generates the project's site documentation

Built-in Lifecycle Bindings

Clean Lifecycle Bindings

Default Lifecycle Bindings - Packaging ear

Default Lifecycle Bindings - Packaging maven-plugin

Default Lifecycle Bindings - Packaging pom

Site Lifecycle Bindings

Buenas prácticas de trabajo de pruebas(unitarias, de Automatice los test

Automatice los test de Automatice los test de Automatice los test

Haga repetibles a los test Limite casos de test a un

Buenas prácticas de trabajo de revisiones (diseño, Reduzca la complejidad del

Revise el diseño en forma Mantenga estándares Reduzca código duplicado

Buenas prácticas de trabajo con releases Instale el software en

Marque en el repositorio los Trabaje en un ambiente Nombre cada release

Gráfico extraído del sitio oficial de CruiseControl

También podría gustarte