Presentacion de Integracion Continua para ExpoQA 2008.

1. Presentación de Integración Continua
Eric Pugh MADRID
27 y 28 de Noviembre

2. ¿Quién soy yo?
 Principal de OpenSource Connections,
una impresa boutique de Agile
Contribuidor de CruiseControl
Miembro de Apache Software
Foundation
Presentador en muchas conferencias,
incluyendo OSCON, ApacheCON, jTDS
Fascinado por el arte del designo de
software
Integración Continua MADRID, 27 y 28 de
Noviembre
Buenos días, me llamo Eric Pugh y soy de Virginia de los Estados Unidos. Por los que no sepan, Virginia es un estado en la costa
este, justo al sur del capital del país, Washington, D.C. Vivo allí con mi esposa Kate y nuestro hijo de un año, Morgan. Pero, hace
tres anos, antes del tiempo de hijos, Kate y yo vivimos por dos anos en Valencia. Era allí, en Valencia, donde me envolví con
opensource software y ???de el arte del designo de software. Así que, me da mucho placer tener la oportunidad de volver a España
y ser una parte de esta conferencia.
Soy el presidente de una empresa que se llama OpenSource Connections. Somos una empresa de programadores de Agile. Hoy
en día, Agile es un tema muy popular, ?Que significa, exactamente? Lo que hago yo es entrenar a los programadores cuando un
equipo quiere usar la metodología de Agile.
También, soy contributor de CruiseControl, que es el sistema de integración continua original. He dado varios discursos sobre
temas de testing, incluyendo integración continua, en conferencias como OSCON, ApacheCON, y Jornadas de Testeo de Software
en Valencia en 2006.
?Por que estoy aquí? Hoy, os voy a hablar de integración continua. Como profesionales de software, trabajamos en un mundo de
cambio constante y fechas topes cortas. Así que, necesitamos herramientas que nos ayuden a superar estos desafíos. Integración
continua es uno de esta herramienta.

3. ¿De qué hablamos?
¿Qué es Integración Continua?
¿Porque esta importante de mi?
¿Qué necesitamos para usar Integración Continua?
Demostración de Hudson
¡Preguntas!
3
Integración Continua MADRID, 27 y 28 de
Noviembre
Vamos a hablar sobre que es integración continua y porque es importante. También, aprendemos de que se necesita para usar
integración continua y cuales son los desafíos iniciales. Vamos a aprender lo que se necesita para un sistema de integración
continua muy exitoso. Hablaremos de las mejores practicas de integración continua y se puede aplicarlas todas a proyectos de
cualquier lengua, como .NET, Java, y otros plataformas. Ayer, Fran durante el keynote hablo sobre Agile y la metodología XP.
Integración continua forma parte de XP, pero esta muy bien para todos los equipos, cualquier proceso que ellos usan.
Al final, habrá una demostración de Hudson, el sistema de integración continua mas popular. Saldréis con la información necesaria
para poner en practica integración continua con vuestras empresas.

4. ¿Qué es Integración Continua?
De la disertación trascendental de Martin Fowler:
“a fully automated and reproducible build,
including testing, that runs many times a day”.
http://martinfowler.com/articles/continuousIntegration.html
4
Integración Continua MADRID, 27 y 28 de
Noviembre
En XXXX, Martin Fowler, científico principal de ThoughtWorks, defino integración continua con estas palabras, “ a fully automated
and reproducible build, including testing, that runs many times a day”. Esta cita se traduce básicamente a “un build totalmente
automático, que incluye el testeo, y que se repite muchas veces cada día”.
Ahora, vamos a ver lo que significa esta cita.

5. Feedback Rápido
< 10 minutos
Integración Continua MADRID, 27 y 28 de
Noviembre
Aquí tenemos el corazón de Integración Continua: un ciclo muy rápido que ocurre muchas veces cada día. Un programador
escribe un poco de código nuevo, que incluye una nueva prueba para la función nueva. Después de Check in el código, el build
empieza automáticamente. El build no es solamente compilar el código, sino que también esta haciendo las pruebas. Sin pruebas,
tenemos solamente una maquina de compilar. Y la información que el código compila esta bien, pero no indica que el código
funciona según los requisitos. Las pruebas son lo que indica que el código funcione según los requisitos, y no hemos introducido
nuevos problemas en el sistema.
La información necesita ir al programador rápidamente. La manera mas típica de enviar la información es por correo electrónico,
pero hay otras maneras también. Por ejemplo, a mi me gusta recibir los resultados por SMS en mi móvil.
El tiempo total por este ciclo no debe pasar los diez minutos. Es mejor check in el código frecuentemente durante el día en vez de
solo una vez al final del día. Así si hay un problema en el código se puede resolverlo rápidamente porque el cambio en el código
esta muy cerca del problema que se ve en el ámbito de Integración Continua. Si el ciclo fuera mas de diez minutos, seria mas
probable que el programador cambiaría su atención a otro asunto como la merienda, la próxima reunión, navegar la red, lo que sea.

6. ¿Cómo es importante la Integración Continua para las siguientes personas?
6
Integración Continua MADRID, 27 y 28 de
Noviembre
En esta conferencia hay personas que representan muchos papeles diferentes. Hay programadores, testers, y jefes de proyecto.
Todas estas personas pueden contribuir al éxito del uso de Integración Continua. Todas las personas reciben información distinta
de Integración Continua también.

7. La vida de un programador sin IC...
 Código inestable, la integración es difícil
Muchos errores de build
Hay solo una persona que puede build el proyecto
Hacer demostraciones es muy difícil
Un ciclo de feedback muy largo
Cada día es una lucha para ser productivo
7
Integración Continua MADRID, 27 y 28 de
Noviembre
El impacto de integración continua es mas significante para los programadores que para cualquier otra persona. Sin integración
continua, la vida de un programador es mas difícil. Un programador funciona en un ambiente con muchos cambios, causados por
otros programadores, cambios en los requisitos, y cambios en las dependencias del sistema. Un programador que cambia el
código necesita integrar los cambios de otros programadores en el mismo código. Por ejemplo, un programador entra en la oficina
para empezar un nuevo día de trabajo y recibe el código nuevo de control de código. Empieza a trabajar y descubre que los
cambios de otras personas del día previo no funcionan con su propio código. Antes de escribir código nuevo, necesita resolver los
problemas que ya existen. Otras veces, el baso de datos es cambiado por otras personas y el programador tiene que encontrar los
cambios y añadir los cambios a su propio baso de datos. Estos cambios resultan en muchos errores del build.
En proyectos sin integración continua, es muy típico que es muy difícil de crear el sistema porque es la responsabilidad de solo una
persona hacer el build. Es peligroso poner toda la responsabilidad de un build en una persona--?Que pasa si esta persona este
enferma, vaya de vacaciones, o simplemente se niegue cumplir sus responsabilidades profesionales?
Otro problema que existe sin integración continua es que hacer demostraciones para los clientes es muy difícil. Reunir todos los
elementos de un sistema es muy complicado, y requiere mucho tiempo y esfuerzo. Así, a los programadores no les apetece hacer
demostraciones.
Por consiguiente, el ciclo de feedback de los clientes y los testers es muy largo, y así probablemente habrá mas problemas en
general.
Sin integración continua, cada día es una lucha para ser productivo.

8. La vida de un programador con IC...
 El proceso para hacer builds es fácil y se
puede repetir
Se eliminan errores humanos
Demostraciones son muy fáciles
El ciclo de feedback es muy
rápido
¡Cada día él sabe que puede hacer código!
8
Integración Continua MADRID, 27 y 28 de
Noviembre
En cambio, la vida de un programador con integración continua es mucho mejor.
Primero, el proceso para hacer builds es fácil y se puede repetir porque se tiene un sistema para hacer builds muchas veces cada
día. Este sistema es muy fácil porque no hay pasos manuales y hay un guión automático para hacerlo.
También, integración continua es un poco como el Gran Hermano de Orwell (en un sentido positivo, digo): los errores humanos son
visibles y corregidos muy rápidamente. Por ejemplo, cuando yo estoy escribiendo código y creo un nuevo archivo, es muy común
que olvido de checkin este nuevo archivo. Con integración continua, recibo un mensaje que el build no funciona porque el archivo
nuevo no esta en control de código. Así, puedo checkin el archivo y el build funciona sin que los otros programadores se den
cuenta.
En adición, las demostraciones son mejores con integración continua. Cuando el cliente quiere ver una demostración, es fácil para
el programador usar un guión y que el sistema entero funciona. El sabe que todo el sistema funciona porque todas las pruebas
tuverion éxito en el ambiento de Integración Continua.
El ciclo de feedback es muy rápido con integración continua. Tan pronto como un problema ocurra, como el de no checkin un
archivo nuevo, el programador recibe un mensaje indicando este problema. El puede resolver el problema rápidamente y todos los
programadores saben que ellos pueden usar el código nuevo sin problemas.
Así, con integración continua, cada día el programador sabe que puede hacer código.

9. Para un tester

control
 ¿Qué hay en el build?
¿Cuáles son los cambios?
¿Cómo se verifica?
9
Integración Continua MADRID, 27 y 28 de
Noviembre
Integración continua también es útil para personas con otros papeles, como los testers. Aunque soy programador, trabajo mucho
con los testers. Fui una conferencia en Tejas que se llama “CITcon: Continous Integration conference”. Y allí un tester, se llama
Elisabeth Hendrickson, me dio esta pulsera que siempre llevo. Dice “Test Obsessed”, o Obsesionado con el testeo. Ella tiene una
pagina de la red a testobessed.com que esta un buen lugar para mas información.
El desafío mas grande para los testers es entender cuales versiones de cuales componentes forman el sistema. Ellos necesitan
saber que ha cambiado entre un build y otro. Cuando entienden lo que forma un build, luego saben el código que se necesita
probar. Por tener builds que tienen pruebas automáticas, ellos pueden enfocar en el código nuevo y no necesitan hacer pruebas
en el código viejo. Al crecer el sistema, la cantidad de trabajo de los testers no aumenta demasiado. Sin integración continua,
ellos necesitan repetir todas las pruebas para todas las funciones porque no saben cuando hay una regresión. Así, los testers
tienen control de los cambios en el ambiente de testeo.
También, cuando los pruebas de integraccion escribi por los testers, ellos conocen que los pruebas corriendo cada vez hay un
cambio de el código. Cuando hay un errores en una prueba automática porque un programador cambiar el código, esta posible por
el programador arreglar la prueba. Integración continua ayuda el comunicación entre los testers y los programadores.

10. Para un jefe de proyecto

visibilidad
10
Integración Continua MADRID, 27 y 28 de
Noviembre
Para un jefe de proyecto, la cosa mas importante es tener acceso a información fiel sobre sus proyectos. Un sistema de
integración continua provee información sobre la salud del proyecto, como cuantas veces cada día hay un error de build o si todas
las pruebas tienen éxito.
Aquí, se ve un ejemplo de siete proyectos en un sistema de CruiseControl. Se ve que todos los proyectos tienen pruebas exitosas,
con la excepción de uno, que se llama hightechcville (en rojo). Sin integración continua el jefe tiene que preguntar a todos los
programadores y testers acerca del estado del código, y esto interrumpe la concentración de todos. Pero, con integración
continua, el jefe tiene una pagina web que muestra los resultados, y así tiene toda la información necesaria al alcance de sus
propias manos. El tiene mucha visibilidad con sus proyectos.

11. Para un jefe de programadores
11
Integración Continua MADRID, 27 y 28 de
Noviembre
Aquí tenemos un ejemplo de un reportaje de Dashboard de integración continua de un cliente nuestro. El cliente tenia código en
muchas lenguas, incluyendo C, Java, y .NET. También, el código estaba en muchos diferentes estados de salud y edad. Ellos
querían un sistema de integración continua para tener mas visibilidad en el código. Así que, introducimos un sistema de
integración continua que contenía muchas herramientas para vigilar la salud del código.
Por ejemplo, se puede ver dos proyectos que no tienen errores, deDupe y JavaCommon y la fecha de creación de la información.
También, podemos ver otro proyecto que se llama MFWS.NET que no tuvo éxito. Con este proyecto, noventa ocho por ciento de
las pruebas tenían éxito, y las pruebas incluyeron solamente veinte tres por ciento del código. Así, este documento tiene mucha
información en cuanto a la salud de los proyectos, y el documento se actualiza cada día.

12. Para un equipo de programadores

seguridad
12
Integración Continua MADRID, 27 y 28 de
Noviembre
Aquí tenemos una foto de dos lamparas de lava. Hay una de color verde y otra de color rojo. Cuando todo esta bien, y no hay
problemas con el build, la lampara de verde esta encendida. Todas las personas del equipo saben que no hay problemas. !Pero!
Cuando hay un problema con el build, la lampara verde se apaga, y la de color de rojo se enciende. Así todo el mundo sabe que
hay un problema con el código y que no es la hora adecuada de bajar el nuevo código, Ellos deben esperar hasta que la persona
que causo el problema reciba un mensaje y arregle el problema. Este tipo de aparato provee información ambiental o “glanceable
information” porque es muy simple para entender.
Otra razón que me gusta usar las lamparas de lava es porque la “lava” es de acera. Y la lampara necesita diez minutos mas o
menos encendida antes de que la lava empiece a mover . Por esta razón, el programador tiene diez minutos mas o menos para
arreglar el problema!
Cuando la lampara verde esta encendida, todos los miembros del equipo saben que la salud del código esta bien!

13. Para un equipo de programadores
13
Integración Continua MADRID, 27 y 28 de
Noviembre
Aquí tenemos una foto de un semáforo que muestra lo que esta pasando ahora mismo en el sistema de integración continua. Este
semáforo se localiza en las oficina de Thoughtworks en Bangalore, India. La luz roja indica que el build ha fracasado. Se puede ver
el proceso del sistema por las luces, empezando en la parte de abajo. Cuando el sistema esta esperando a hacer un build, la luz
mas al fondo esta encendida, y después cuando el código esta compilando, la próxima luz se enciende. Durante la fase de las
pruebas, las terceras y cuartas luces están encendidas.

14. Para un equipo de programadores
14
Integración Continua MADRID, 27 y 28 de
Noviembre
Este es un ejemplo de un tablón de anuncios usado por uno de nuestros clientes para compartir información sobre el estado del
proyecto. Los varios reportajes están producidos cada noche por el sistema de integración continua. El tablón de anuncios esta en
una área publica, donde personas que forman parte del equipo de programadores tanto como personas afuera del equipo pueden
verlo. Hay reportajes sobre la complejidad del código, resultados de pruebas, y estimaciones en cuanto al trabajo que queda por
hacer.
Este tipo de tablón de anuncios a menudo se llama un “radiador de información” porque mucho gente ver lo, sin ir a una pagina del
web.

15. Para un equipo de programadores
15
Integración Continua MADRID, 27 y 28 de
Noviembre
Aquí se ve una versión “high-tech” del previo tablón de anuncios que se usa un monitor de pantalla grande para mostrar los
resultados de los builds en el sistema de integración continua.

16. ¿Qué necesitas para empezar?
 Una máquina dedicada
Source Control
Build Script Automática
Sistema de notificación
16
Integración Continua MADRID, 27 y 28 de
Noviembre
Bueno, hasta aquí hemos hablado de lo que es la integración continua y cuales son los beneficios de usarla. Pero, ?como
empezamos?
La primera cosa que se necesita es una maquina dedicada solo para la integración continua. Integración continua causa muchos
builds cada día y es demasiado trabajo anadir este trabajo a una maquina no dedicada exclusivamente para este sistema.
La segunda cosa que se necesita es un sistema de control de código, como Subversion, CVS, o Visual Source Safe. El sistema de
control de código contiene todo el código con lo cual las personas trabajan y asegura que no hay conflictos en el código causados
por mas de una persona haciendo cambios a la vez. Todo debe ser una parte de control de código, incluyendo el código, pruebas y
guiones para hacer el build.
El sistema de integración continua vigilara el control de código para cambios y cuando encuentra un cambio, bajara en nuevo
código y empezara un build. Es muy importante que el build sea un guión automático. Los builds no pueden contar con un IDE
como Eclipse o Visual Studio porque todo tiene que pasar usando un guión. Si una ventanilla de pop-up aparece, el build se
atasca, esperando una respuesta de una persona que no existe. Hay muchas herramientas que se puede usar para escribir un
guión, como ANT, MAKE, NANT, MSBuild, dependiendo en su entorno.
El éxito o fracaso de un build no significan nada si nadie sepa que haya pasado. El método mas común de notificar es por correo
electrónico, pero hay muchos otros métodos posibles, incluyendo SMS, Jabber, y RSS.

17. ¿ Cuáles son los desafíos de usar IC?
17
Integración Continua MADRID, 27 y 28 de
Noviembre
Después de tener los requisitos para empezar a usar integración continua, hay 4 desafíos posibles que hay que superar. Hay
desafíos de cultura, de ambiente, de los proyectos y de la herramienta de integración continua. Vamos a hablar de estos desafíos
posibles y como se pueden resolver.

18. Desafío Uno: Un cambio de cultura
 IC necesita un campeón que es un embajador para los jefes de la
empresa.
Lideres de pensamiento de la empresa que pueden convencer a los
desarrollador a aceptar los cambios
 Nesscita una prueba caso muy
exitoso.
¿Un nuevo proyecto es posible?
18
Integración Continua MADRID, 27 y 28 de
Noviembre
El primer desafío posible es que integración continua es un cambio de la vida normal para las personas en el equipo, así
representa un cambio de cultura. Tal vez los programadores perciben a integración continua como un Gran Hermano que destaca
todos sus errores con luces rojas o mensajes enviados a su equipo. También, ellos pueden pensar que la necesidad de escribir
pruebas como mas trabajo. Por eso, hay que tener un campeón para integración continua: una persona respetada que sea un líder
de pensamiento dentro de la empresa. Esta persona asegura que el sistema es para ayudar a los programadores y que las
pruebas resultan en mejor código con menos errores. En adición, el campeón necesita explicar a los jefes por que necesitan cosas
como una maquina dedicada, tiempo para mantener el sistema, y cuales son los beneficios generales para la empresa.
Para empezar a usar integración continua, es mas fácil si tienes un proyecto nuevo en que los procesos no han sido establecidos
anteriormente. Así, desde el empiezo estas creando el código usando un guión automático y hay pruebas para todo el código.
Con el ejemplo de un proyecto exitoso de integración continua, otros equipos de programadores querrán empezar a usarla
también, especialmente si se puede ver públicamente los resultados de los builds. La primera vez que se me olvido de check in un
archivo nuevo y recibí un mensaje, es cuando yo me convertí en un “creyente” de integración continua.

19. Desafío Dos: Desafíos Ambientales
 Todas las pruebas de unidad son pruebas de
unidad verdaderas, no son pruebas de
integración
No hay mucha dependencia externa
Un build server para IC es muy fuerte
Hay estrategia para poner nuevo código en el
IC ambiente
Es fácil para cambiar el base de datos
19
Integración Continua MADRID, 27 y 28 de
Noviembre
A menudo, la gente dice “Mi proyecto es demasiado complejo para usar integración continua”. Sin embargo, hay que integrar todos
los componentes del sistema en un sistema grande. Esperar al fin del proyecto solo aumenta los riesgos de integración. La mejor
manera de simplificar el proceso de integración es hacerlo muchas veces.
Por escribir guiones automáticos, se quita la complejidad por hacer cosas como separar las pruebas de integración que requieren
dependencias externas de las pruebas de unidad. Se desarrolla maneras de fingir dependencias externas para que sea mas fácil
de build y probar el código.
A menudo es difícil publicar el código a un ámbito de pruebas, pero por hacerlo frecuentemente en el ámbito de integración
continua, muchas veces al día, se quita cualquier debilidad en el proceso de despliegue en cualquier ambiente.
A veces cuando hay muchos proyectos en integración continua, los builds se acumulan y requieren mucho tiempo. Este frustra a
los programadores porque ellos esperan los resultados. Cuando esto pasa, puedes conseguir una maquina mas fuerte y cambiar
las pruebas para separar pruebas de integración de pruebas de unidad. Es típico hacer las pruebas de integración durante la
noche.
La dependencia externa mas común es un base de datos controlado por un administrador de base de datos. Con un ámbito de
integración continua en que se hace pruebas muchas veces al día, hay que fijar de nuevo la información en el base de datos sin
intervención humana.

20. Desafío Tres: Características del proyecto
 Es fácil cuando no hay muchas divisones del código
Hay muchos cambios pequeños. Hay cambios constantemente
durante el día.
Hay pruebas de unidad para todo el codigo
El código está listo para producción
20
Integración Continua MADRID, 27 y 28 de
Noviembre
?Como se verifica si un proyecto se puede adaptar fácilmente a la integración continua?
El código que solo tiene un tronco es mas fácil para el sistema de integración continua de vigilar. Cuando los requisitos del proyecto
se estructuran para que varias personas puedan trabajar en partes diferentes a la misma vez, ellos pueden checkin los cambios
frecuentemente sin preocuparse de crear conflictos. Cuando hay buenas pruebas de unidad de todo el código, hay mas confianza
en los resultados del build del sistema de integración continua son verdaderas. El build es mas que solo una compilación. El código
que esta escrito bien sin complejidad y con pruebas es mejor para usar con integración continua.

21. Desafío Cuatro: Estabilidad de herramienta de IC
X
 El sistema de integración continua es tan
importante como el sistema de control de
codigo.
El sistema de IC puede hacer builds muy
rápidamente.
¿Quién tiene la responsabilidad para IC? Es
muy importante que haya una persona con
responsabilidad para IC.
✓
No hay alarmas falsas. Si hubieran alarmas
falsas, los programadores no tendrían confianza
en IC
21
Integración Continua MADRID, 27 y 28 de
Noviembre
Como cualquiera herramienta, el sistema de integración continua puede tener problemas de funcionamiento si no se lo mantiene
con cuidado.
Por ejemplo, hace dos años visite una empresa y les pregunte si usaban la integración continua y el jefe de programadores me
dijo, “Si, lo usamos, y funciona muy bien. Nuestros builds deben funcionar perfectamente porque no hemos recibido ningún
mensaje de fracaso por meses”. Mas tarde, hable con uno de los programadores y el me confío que tampoco habían recibido
ningún mensaje de éxito por meses. Ellos habían cambiado la versión de Java usada por el proyecto y nunca habían cambiado el
sistema de integración continua para usar la nueva versión de Java. El sistema de integración continua envío un mensaje de
fracaso y había estado en un estado de fracaso desde entonces.
Para que funcione integración continua, hay que cambiarla según cambias los ambientes de los programadores y del testo. El
ejemplo que acabo de daros muestra lo que puede pasar si no haya una persona encargada de vigilar la salud del ambiente de
integración continua.
Otro ejemplo de un problema de funcionamiento evitable ocurrió en otro proyecto. Usábamos integración continua para enviar
mensajes cada diez minutos cuando el build no tenia éxito. Enviamos los mensajes por SMS a nuestros móviles y una vez hubo
un problema con una dependencia externa y yo recibí cuarenta y cinco mensajes en mi móvil. Aquel día, obviamente a mi no me
gusto el sistema de integración continua mucho porque no me ayudo, solo me molesto. Tenia que eliminar cuarenta y cinco
mensajes de texto en dos minutos.
Sin embargo, un sistema de integración continua bien mantenido no tiene estos problemas.

22. Demostración de Hudson
22
Integración Continua MADRID, 27 y 28 de
Noviembre

23. ¿Como se sigue?
 Continuous Integration: Improving Software Quality
and Reducing Risk
Introducción de Hudson: http://xnoccio.com/362-
hudson-parte-1-introduccion/
CITConf es la conferencia sobre IC
23
Integración Continua MADRID, 27 y 28 de
Noviembre
?A donde vamos para aprender mas del tema de Integración Continua? Me encanta el libro que se llama “Continuous Integration:
Improving Software Quality and Reducing Risks” escribe de Paul Duvall. Es de la serie que se llama “Martin Fowler Signature
Book”, y tiene toda la información sobre Integración Continua en un libro.

24. El matriz de 22 diferentes sistemas de IC
http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
24
Integración Continua MADRID, 27 y 28 de
Noviembre
En esta pagina web hay un matriz de veinte dos sistemas de integración continua, incluyendo sistemas de Open Source y sistemas
comerciales. Hay mucho información sobre las capacidades de los sistemas, incluyendo el tipo de control de código apoyado,
tipos de Build Management, y mucho mas.

25. ¿Porque Integración Continua?
Eliminar los errores humanos
Las prueba corriendo mucho veces tiene mas beneficioso
Una sistema puedes hacer reportes de la salud del proyecto
¡Eliminar problemas de integración!
25
Integración Continua MADRID, 27 y 28 de
Noviembre
En resumen: ?Porque Integración Continua?
Hay cuatro razones claves:.
Numero uno es la eliminación de los errores humanos. Los errores humanos crean problemas para comunicación en el equipo.
Numero dos es que las pruebas son mas beneficiosas cuando ocurren muchas veces, y el tiempo entre la introducción de un
problema y la resolución del problema es muy corto.
Numero tres es que un sistema de integración continua es la fundación para un sistema de reportaje sobre la salud de los
proyectos.
Y la ultima razón es la eliminación de los problemas de integración, y por eso, la reducción del riesgo.

26. Eric Pugh epugh@opensourceconnections.com MADRID
27 y 28 de Noviembre
Gracias por vuestra atención. Ahora, por favor, haga cualquier pregunta que tengáis. Y también, cuando vosotros regresáis a
vuestras empresa, podéis enviar cualquiera pregunta a por email a epugh@opensourceconnections.com!
Muchísimas gracias.