Camino hacia la integración continua

El responsable del desarrollo mira al techo y piensa:

– Bien, ya sé que la calidad del código es importante. Que hay que organizar el trabajo de los desarrolladores para detectar los errores cuanto antes, introducir métricas… pero… ¿Por donde empiezo?

Existen una serie de fases o estados por los que pasa un equipo de desarrollo en el camino que nos lleva a la implantación de un sistema de integración contínua. Vamos a ver cuales son:

Estado 1: Sin servidor de desarrollo o compilación (build Server)

Inicialmente, el equipo no tiene un centro servidor de generación de cualquier tipo. Software está construido manualmente en la máquina del desarrollador, aunque puede utilizar un script de Ant o similar a hacerlo. El código fuente puede ser almacenada en un repositorio de código fuente central, pero los desarrolladores no necesariamente suben sus cambios sobre una estructura ordenada o estandarizada. Algún tiempo antes deque un lanzamiento esté programado, un desarrollador de forma manual integra los cambios, un proceso que generalmente se asocia con el dolor y el sufrimiento.

Estado 2: Compilaciones nocturnas

El equipo tiene un servidor de compilación y se programan de forma regular compilaciones automatizadas (por lo general todas las noches). Esta versión sólo compila el código, ya que no hay pruebas unitarias fiables o repetibles. De hecho, las pruebas automatizadas, si están escritas, no son una parte obligatoria del proceso de construcción, y bien no funcionan correctamente en todos los entornos. Sin embargo, ahora los desarrolladores suben sus cambios con regularidad, por lo menos al final de cada día y con una estructura normalizada. Si un desarrollador sube cambios de código que entran en conflicto con el trabajo de otro desarrollador, el servidor de compilación alerta al equipo por correo electrónico a la mañana siguiente. Sin embargo, el equipo todavía tiende a utilizar el servidor de compilación sólo con fines informativos (los desarrolladores no se sienten en la obligación de reparar un bug de inmediato, y las compilaciones pueden estar fallando por algún tiempo.

Estado 3: Compilaciones nocturnas y pruebas básicas automatizadas

El equipo ahora está empezando a tomar de integración continua y pruebas automatizadas con más seriedad. El servidor de compilación está configurado para dar inicio a una compilación cada vez que el nuevo código se ha subido al sistema de control de versiones, y los miembros del equipo son capaces de ver fácilmente lo que desencadenan los cambios en el código una determinada compilación. Además, los scripts compilan la aplicación y ejecutan un conjunto de pruebas unitarias o de integración. Además del correo electrónico, el servidor de compilación también alerta a los miembros del equipo de los problemas de integración con los canales más proactivas, como la mensajería instantánea. Los programadores están más concienciados y los errores se corrigen ahora rápidamente.

Estado 4: Se introducen métricas

 Se mide y evalúa la calidad del código y (hasta cierto punto, por lo menos) la pertinencia y eficacia de las pruebas. También se genera automáticamente documentación de la API para la aplicación. Todo esto ayuda a los equipos mantener la calidad del código, alertando a los miembros del equipo si las buenas prácticas de las pruebas se están relajando. El equipo muestra esta información un panel prominente, visible a todos los miembros del equipo.

Estado 5: Test cada vez más exhaustivos

Los beneficios de la integración continua están estrechamente relacionados con las prácticas de pruebas sólidas. Ahora, las prácticas análogas a “Test-Driven Development” (desarrollo basado en pruebas) se han adoptado más ampliamente, dando lugar a una creciente confianza en los resultados de las compilaciones automatizadas. La aplicación ya no es compilada y probada simplemente, si pasa las pruebas, se distribuye automáticamente a un servidor de aplicaciones para realizar pruebas más completas de extremo a extremo y pruebas de rendimiento.

Estado 6: Se automatizan las pruebas de aceptación y se mejora la automatización de despliegue

Se guían los esfuerzos de desarrollo y la disponibilidad de informes de alto nivel sobre el estado del proyecto. Estas pruebas automatizadas utilizan un enfoque de desarrollo orientado al comportamiento y a la aceptación “Behavior-Driven Developmen”t y “Acceptance-Test Driven Development”. Se publican informes de los resultados de los test, en términos de negocio, que los no desarrolladores pueden entender. Puesto que estas pruebas de alto nivel se realizan automáticamente en una etapa temprana en el proceso de desarrollo, proporcionan una idea clara de qué características se han implementado, y cuales aún no se han hecho. La aplicación se instala automáticamente en los entornos de prueba para las pruebas de control de calidad, cuando se sube un cambio al svn, o bien por las noches. Se puede desplegar a producción con un “trigger” o disparador manual, cuando lo consideren oportuno. Se pueden crear “releases”, o volver a una release anterior si algo va mal.

Estado 7: Despliegue continuo

La confianza en la unidad automatizada de integración y pruebas de aceptación es tal que los equipos pueden aplicar las técnicas de implementación automatizados desarrollados en la fase anterior para empujar a cabo nuevos cambios directamente en la producción.

Conclusiones

Como se puede ver existe una gran escala de grises, entre el desarrollo de aplicaciones de manera desorganizada y la implantación total de un sistema de integración continua. Esto va más allá de la simple configuración de servidores y herramientas que automaticen las tareas de desarrollo, sino que requiere además definir unas normas de desarrollo y una implicación de los desarrolladores para que acaten dichas normas.

En el próximo artículo hablaremos sobre el sistema de control de versiones Git, y en los siguientes continuaremos viendo los distintos elementos que nos llevarán al desarrollo de un sistema de integración continua.

2 comentarios:

  1. Muy buen artículo, me gustaría sin embargo que publicaras bibliografía que hayas leído y que por consecuencia te ayudara a escribir el artículo.

    • Hola Iván,

      Bien, el libro que más me ha gustado sobre el tema, es:

      – “Jenkins the definitive guide”, de John Ferguson Smart
      También es fundamental empaparse bien de Maven, en Sonatype puedes encontrar “Maven: The Complete Reference”, o leer directamente la documentación de la plagina de Apache Maven.

      Relacionado con este mundillo, entraríamos con temas de testing, (tdd, bdd, automatización de pruebas, etc.). Te comento algunos que me han gustado:
      – Test Driven de la editorial Manning
      – Test-Driven Development By Example, del gurú sobre estos temas Kent Beck
      – Diseño Agil con TDD, de Carlos Blé y otros
      – Selenium 2 Testing Tools de David Burns

      También me parece interesante el tema de BDD, no he encontrado ningún libro “redondo” que merezca la pena comentar, pero se puede buscar por internet artículos sobre BDD y Cucumber. De hecho, tengo pendiente escribir un artículo sobre ello…

      Saludos

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *