Lo que espero conseguir con la integración continua

Hace algún tiempo escribí un breve post para dar una pincelada sobre lo que entiendo por integración continua. Una de las cosas que comentaba era que no había tenido la oportunidad de poner en marcha este modo de interaccionar en proyectos reales, sin embargo, ahora ya tengo algunas experiencias y me estoy haciendo una idea de lo que quiero conseguir. Quizás más adelante pueda contar lo que sí estoy consiguiendo, pero esto es otro tema porque no sólo depende de los conocimientos teóricos, de las herramientas disponibles o la infraestructura necesaria, sino que depende de hacer ver a todos los miembros del grupo lo realmente positivo que puede llegar a ser este modo de trabajar, de que los miembros superen cierta curva de aprendizaje y de que en el sitio donde llevas a cabo tu trabajo te permitan modelar este tipo de prácticas.

Ahora lo interesante es conocer qué nos puede aportar la integración continua, que si Martin Fowler me lo permite, voy a referirme a ella como una práctica en la que lo todo gira en base a dos cuestiones:

  1. Diseñar mecanismos y procedimientos para que los efectos de tus causas puedas controlar. Cuando estamos desarrollando, implementar una cierta funcionalidad o subir la versión de una librería, y que posteriormente esto se refleje en nuestro sistema de control de versiones, tiene su efecto. En este caso la causa sería el commit. Pues bien, si ese commit va acompañado de pruebas unitarias, pruebas de sistemas y pruebas de integración, podremos conocer el verdadero efecto de la causa. Si el efecto es el esperado, perfecto!, en caso contrario habrá buscar otra causa para alcanzar el efecto deseado.
  2. Y por otro lado, la automatización de esos mecanismos y procedimientos. Será la automatización la que nos permita centrarnos en lo verdaderamente importante, la solución de los problemas. ¿Cuántos grupos de trabajo conocéis que sean todos y cada uno de sus miembros lo suficientemente cuidadosos, delicados y meticulosos con su trabajo para tener la certeza de que los pequeños detalles no quedan ocultos? Cómo esta situación es difícil de encontrar y en caso de encontrarla la productividad de la empresa nos agobiaría, necesitamos hacer algo que nos proporcione indicadores que reflejen todos los detalles (grandes y pequeños) y que por otro lado no tengamos que repetir una y otra vez las mismas acciones de forma manual.

Lo que buscamos es algo que nos permita modelar mecanismos y procedimientos que se puedan ejecutar o realizar de forma automática y que nos hagan ver claramente los efectos de todas las causas que se originan.

Algunos ejemplos de efectos que se me ocurren en este momento pueden ser:

  • Generación de documentación. Como responsable de QA no quiero llevarme la desagradable sorpresa de que tras cuatro meses de desarrollo la documentación Javadoc que se ha generado no está lo suficientemente elaborada. Necesito algo que todas las noches me genere la documentación Javadoc y la publique a través de HTTP en formato HTML.
  • Despliegues automáticos de las releases del proyecto. Los tester no pueden estar esperando a que alguien les depliegue una determinada versión del proyecto (o producto, en este caso daría igual) para continuar con su trabajo.
  • Análisis de código. No quiero esperar a tener un poco de tiempo libre en el que poder ejecutar mi plugin PMD o Clover y darme cuenta de lo que se está haciendo y cómo se está haciendo.
  • Integración. No quiero estar al 80% de un proyecto y darme cuenta de que el proyecto únicamente se ha probado con JDK1.5 en Jetty y la respuesta sea que no hubo tiempo para otras pruebas. Efectivamente, es posible que no haya tiempo si esas pruebas las tienes que hacer manualmente y encima tienes que mantener todos estos entornos, sin embargo, de poder automatizarlo, el tiempo no sería tu principal problema.

Estos son sólo algunos de los ejemplos que se me han ocurrido, sin embargo, la lista podría ser más extensa. Pues bien, en cada uno de esos ejemplos están los objetivos que pretendo conseguir con la integración continua. La solución está en los ecosistemas de software, ¿verdad Brett? Estoy prácticamente seguro que Carlos Sánchez opina lo mismo y máxime cuando le de algunos ingredientes como maven, Mylyn, archiva, continuum, etc.

Leave a Reply

Your email address will not be published. Required fields are marked *