SlideShare una empresa de Scribd logo

Integracion Continua

•
•
OpenSource Connections
OpenSource Connections

Este documento presenta una introducción a una presentación sobre integración continua que será dada por Eric Pugh en Madrid los días 27 y 28 de noviembre. Se presenta a Eric Pugh y su experiencia en software de código abierto y metodologías ágiles. La presentación cubrirá qué es la integración continua, por qué es importante, qué se necesita para implementarla y una demostración del sistema de integración continua Hudson. El objetivo es que los asistentes obtengan la información necesaria para aplicar la integración continua en sus propios proyect

Presentaciones relacionadas

Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
DevOps Presentation.pptx
DevOps Presentation.pptxDevOps Presentation.pptx
DevOps Presentation.pptx
 
Fundamentals of DevOps and CI/CD
Fundamentals of DevOps and CI/CDFundamentals of DevOps and CI/CD
Fundamentals of DevOps and CI/CD
 
1 de 26
Descargar para leer sin conexión
Presentación de Integración Continua Eric Pugh MADRID 27 y 28 de Noviembre
¿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.
¿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.
¿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.
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.
¿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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
¿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.
¿ 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.
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.
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.
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.
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.
Demostración de Hudson 22 Integración Continua MADRID, 27 y 28 de Noviembre
¿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.
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.
¿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.
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.

Más contenido relacionado

Integracion Continua

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