Non nobis Domine...
Isaac Ruiz Guerra's Weblog
- Todo
- Internet
- Politica
- frases
- ruby
- ESB
- Libros
- Oracle
- SOA
- Haskell
- Urbi
- 97things
- Humor
- General
- Justicia Social
- Cine
- Java
- TecNo
[5 de 97] Integrar Continuamente.
El axioma de hoy, aparece en la página 40 del libro 97
things Every Software Architech Should Know , y dice:
"Continuously Integrate"
David Bartlett.David Bartlett es un entusiasta del software con más de 25 años de experiencia como programador, promotor, arquitecto, gerente, consultor e instructor.
Actualmente trabaja para clientes a través de Commotion Technologies, Inc., tiene un Master en Ingeniería en Diseño de Software y un MBA de la Universidad Estatal de Pennsylvania.
Vive con su familia en Berwyn, Pensilvania, EE.UU.
The build as a "big bang" event in project development is dead. The architect, whether an application or enterprise architect, should promote and encourage the use of continuous integration methods and tools for every project.
The term Continuous Integration (CI) was first coined by Martin Fowler in a design pattern. CI refers to a set practices and tools that ensure automatic builds and testing of an application at frequent intervals, usually on an integration server specifically configured for these tasks. The convergence of unit testing practices and tools in conjunction with automated build tools makes CI a must for any software project today.
The most prominent part of a CI implementation is the build which is usually automated. You have the ability to do a manual build but they can also be kicked off nightly or can be triggered by source code changes. Once the build is started the latest version of the source code is pulled from the repository and the CI tools attempts to build the project then test it. Lastly, notification is sent out detailing the results of the build process. These notifications can be sent in various forms including email or instant messages.
Continuous Integration will provide a more stable and directed development effort. As an architect you will love it but more importantly your organization and your development teams will be more effective and efficient.
Creo que a estas alturas ya no está en discusión si debemos o no implementar un mecanismo de integración continua en nuestro desarrollo, creo qué lo que debe estar a discusión es "cuándo y de que manera( y que herramientas utilizar)".
¿Cuando? mmmm, creo que si estamos por iniciar un desarrollo debemos considerar seriamente agregarlo desde el inicio, y aún cuando no estemos dispuestos a utilizar una metodología ágil al 100%, muy probablemente aún así nos será útil.
Si ya tenemos un desarrollo iniciado, quizá la mejor estrategia es ir agregando de manera gradual y discreta el servidor/mecanismo de integración continua hasta que consideremos que el equipo de desarrollo esta listo para recibir la noticia ;)
¿Que herramientas utilizar?
Bueno, para este punto, recomiendo ampliamente una serie de post's de Félix García Borrego:
Quisiera argumentar el porqué, cuando se intenta agregar Integración Continua a un desarrollo ya iniciado, debemos hacerlo de una manera "discrecional".
En primer lugar, y es algo que todos hemos vivido en carne propia; si de por sí llevar un desarrollo a buen puerto es una tarea compleja, el asunto se puede complicar más si pretendemos hacer que el equipo de desarrollo se líe ahora con un factor adicional de cambio; cualquier hábito es menos doloroso de adquirir si se hace gradualmente, además puede servir para calibrar a todo el equipo y saber que tanto costará después adoptar por completo una metodología ágil.
Y, hay mucho material para intentar entender como manejamos, administramos y nos resistimos al cambio en nuestras mentes, pero, adicionalmente al cambio, creo que Martín en su post: Integración continua y avergonzamiento público le dio al clavo a otra razón que evita la adopción de esta buena práctica.
El sólo saber que algo puede poner en evidencia que hemos hecho algo mal, muy seguramente dada nuestra naturaleza, hará que evitemos ese algo.
Y es que, <comentario_paranoide> a veces pareciera que las prácticas de algunas metodologías se empeñan en violentar la intimidad del desarrollador</comentario_paranoide>, pero, parafraseando a Martín: a mediano y largo plazo se vuelven evidentes los beneficios obtenidos de esta práctica y se demuestra con hechos que; la tranquilidad de todo el equipo puede compensar una "incomodidad" (seguramente temporal) de algunos padawan's.
Si por alguna razón en la práctica no es posible agregar un servidor de integración continua en nuestro desarrollo, existe una técnica manual que puede ayudar mucho:
Cada cierto tiempo, semanalmente por ejemplo, debemos descargar todo el código de nuestro proyecto desde el repositorio hacia una PC "limpia" y debemos verificar que se puede generar el último distribuible (jar,war,ear) sin problemas.... {si no hay repositorio de código entonces, creo que alguien debe agregar un item más a su matriz de riesgo. ;P}
Para concluir esta entrada, me gustaría recomendar el podcast número 45 de javaHispano, en él se hace una entrevista a Jose Manuel Beas, Xavier Quesada, Xavi Albaladejo quienes se encuentran detrás de la comunidad http://www.agile-spain.com/ ,dentro de la entrevista, además de darnos un panorama general de las metodologías ágiles, hacen valiosos comentarios sobre la integración continua.
En fin, más allá de los dolores de cabeza que pueden generar introducir nuevas prácticas, tratemos de aprender siempre con una sonrisa ;)
Saludos a todos!!
RuGI
Isaac Ruiz Guerra.
Posted at 08:02PM jun 14, 2009 by Isaac Ruiz Guerra in 97things | Comentarios[10]
Felicitaciones por tu artículo Rugi, está muy bueno.
Hace poco leí el artículo de Integración Contínua de Martin Fowler, y recordé una de las recomendaciones que daba era de colocar "lava lamps": unas lámparas roja y verde para indicar si un build estaba roto o si por el contrario estaba correcto.
Saludos y sigue así que tus aportes están muy buenos.
Enviado por Germán G. en junio 14, 2009 a las 10:52 PM CDT #
Muy bueno, creo que estos artículos del Domingo se me van a hacer un visio.
Un abrazo desde aquí señoron.
Saludos!
Enviado por Israel Gaytan en junio 14, 2009 a las 11:50 PM CDT #
Hola RuGI.
El tema de la implantación de la ic no es sencillo. Lo primero los proyectos deben estar preparados. Principalmente tener un alto grado de portabilidad y por supuesto tener tests. Si no tienes tests, la ic pierde casi todo su valor.
Yo recomiendo aprovechar alguna reunión mensual para xplicar el concepto e intentar reclutar algun voluntario para ayudar a implantarlo.
Una vez en marcha y durante las primeras semanas, será usado por el tech lead para ir dando 'toques' de atención porque se haya roto el build o tests que fallen que aprovechará para ir enseñando las bondades de la ic.
En mi experiencia, fuera de los voluntarios, el resto del equipo suele pasar por una fase inicial de esquiva total hasta llegar al enamoramiento. Pero es un camino largo...
Animo!
Te dejo un post donde detallo un poco más mi experiencia con la implantación de Hudson (cuña publicitaria on) -> http://jcesarperez.blogspot.com/2008/12/2-meses-despus-de-hudson.html
Enviado por jcesarperez en junio 15, 2009 a las 02:18 AM CDT #
Mis dos céntimos:
En estos momentos de mi vida, cualquier organización de proyecto software que no utilize un servidor de ic no me merece el más mínimo respeto. Así de claro y radical , pero es que cuando has usado uno te das cuenta que todos tus proyectos anteriores que no lo han usado han sido como pollos sin cabeza en determinados momentos (arranca la cabeza a un pollo vivo y sabrás de lo que hablo ;-)).
[[Sigue el comentario]]
Enviado por ibon en junio 15, 2009 a las 03:22 AM CDT #
En cuanto a la implantación: las dos primeras semanas se me queja todo el mundo, no entienden porque quiero instalar un ci, y me llaman el pesado cada vez que les aviso que han roto el build. Después de eso, ya NINGÚN programador (que quiera ser "profesional") puede vivir sin él. Asi que lo siento, pero si alguien me discute las bondades del ci, dejo de tomarle en serio ;-)
¿Que servidor usar? Si usas ant y/o maven, no hay duda: HUDSON. Si no los usas, yo diría que también ;-) Creo que la infraestructura no debe ser costosa de configurar (porque si lo es, se deja de configurar bien ;-)), y hudson en eso es una delicia.
[[Y sigue... Rugi, 1000 characters?]]
Enviado por ibon en junio 15, 2009 a las 03:23 AM CDT #
[[Fin de ladrillo]]
Y un pequeño detalle, que puede iniciar una discusión ;-) : nada de builds a determinados intervalos, los builds deberían ser lanzados siempre por cambios en el servidor de versiones. ¿Cada cuanto debería mirar el servidor de ci si hay changesets? Lo antes posible, pero que no sea inferior al tiempo de build de tu proyecto (para no cargar tu servidor de builds paralelos, a los que no veo mucho sentido).
Salu2
Enviado por ibon en junio 15, 2009 a las 03:24 AM CDT #
Algún día, tengo esperanza, el sitio donde trabajo entrará en el nuevo siglo. De momento seguimos anclados en muchas cosas en los años 60 o así.
Es lo que hay :(
Enviado por GreenEyed en junio 15, 2009 a las 06:04 AM CDT #
@jcesarperez sí, el tema es algo complejo... , gracias por el link,.... te tengo ahora en mis feeds!! ;)
@ibon... mil gracias por los comentarios sé que no soy el único que toma tus recomendaciones como polvo de oro,
y, mil disculpas, aún no encuentro dónde configurar que los comment's sean más largos :S
Hombre @GreenEyed, que te puedo decir.... haremos votos para que esta situacion cambie pronto ;)
@israel, @german gracias por los ánimos ;)
Saludos a todos..
RuGI
Enviado por RuGI en junio 16, 2009 a las 10:35 AM CDT #
@ge, emplea la táctica de la sopa de piedras (Pragmmatic programmer), a mi me dió muy buen resultado: sólo necesitas un tomcat en tu máquina y acceder al svn de vuestros proyectos. Y haz ic "silencioso": aunque no haya tests, sólo el hecho de mostrar quien rompe el build (y TODOS lo rompemos alguna vez) seguro que anima a más de uno.
Un saludo muy grande, aitatxo! ;-)
Enviado por Ibon Urrutia en junio 16, 2009 a las 02:55 PM CDT #
@Rugi, gracias a tí: me parece una de la mejor series de blogs técnicos ÚTILES que he leído desde hace tiempo... que uno ya está aburrido de leer "tontás" escritas en la cresta de la ola geeky que toque en cada momento.
Con lo fácil que es compartir la experiencia sincera y humilde de unos "probres" progamadores como nosotros, que sólo aspiran a hacer correctamente su trabajo, y que se haga tan poco...
Pues eso, que espero con ganas el próximo post... y espero que la serie quede como referencia hispana de buenas prácticas... así que ánimo y al toro!! ;-)
Enviado por Ibon Urrutia en junio 16, 2009 a las 03:03 PM CDT #