Integracion Continua

Eric Pugh MADRID

Presentación de Integración Continua

27 y 28 de Noviembre

Integración Continua MADRID, 27 y 28 de Noviembre

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

¿Quién soy yo?

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

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?

http://martinfowler.com/articles/continuousIntegration.html

De la disertación trascendental de Martin Fowler:

“a fully automated and reproducible build, including testing, that runs many times a day”.

4

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

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

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

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

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

¿Qué hay en el build?

¿Cuáles son los cambios?

¿Cómo se verifica?

control

9

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

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

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

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

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

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

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

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

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

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

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

?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

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

✓

X

21

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


¿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

?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

24

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix

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

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 [email protected] 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 [email protected]!

Muchísimas gracias.

mailto:[email protected]

mailto:[email protected]

Technology

Integracion Continua