La integración continua en el desarrollo de software

La integración plantea problemas de sobra conocidos por aquellos que se dedican al desarrollo de software: se escribe un código nuevo que desempeña una tarea crucial, el código fuente se implementa en el proyecto y aparecen los problemas. Con el objetivo de evitar una catástrofe al final de una larga fase de desarrollo, muchos equipos deciden aplicar la integración continua (continuous integration en inglés), con la que los cambios se implementan todos los días directamente en el proyecto, a poder ser, varias veces al día.

Al igual que la entrega continua, la integración continua es una práctica muy común sobre todo en el ámbito del desarrollo de software ágil. El objetivo de este moderno enfoque es trabajar a pasos pequeños con el fin de lograr un proceso de desarrollo más efectivo y poder reaccionar con más flexibilidad antes los cambios. La integración continua fue mencionada por primera vez en la definición de Kent Beck sobre la metodología de programación extrema (eXtreme Programming). No obstante, esta idea ya existía con anterioridad y se aplicaba, por ejemplo, en el método Booch.

La integración continua supone una solución para escenarios como el siguiente: una empresa trabaja en un proyecto de gran envergadura, que consiste en el desarrollo de un complejo software para un cliente. Los equipos diseñan aspectos parciales de la aplicación y los desarrolladores programan las distintas funciones. Tras varios meses o incluso años de trabajo, debe montarse y compilarse todo el software y es aquí donde aparecen los problemas. En estos casos, podría tardarse meses en detectar y pulir todos los fallos, unir todos los fragmentos de código y llevar el software a las fases de prueba y despliegue.

En la integración continua, el código nuevo se añade mucho antes y no cuando todos los implicados han concluido su parte. Los desarrolladores integran su código una o varias veces al día en la línea principal (main line), el código fuente al que todos los programadores pueden acceder. Puesto que se trata de pequeños fragmentos de código, la integración se realiza rápidamente y, en tan solo unos minutos, el desarrollador puede poner su trabajo a disposición del resto del equipo. Si se descubre algún error en este proceso, se podrá localizar y solucionar rápidamente.

En la práctica, la integración continua se aplica del siguiente modo: un ingeniero debe desarrollar una función. Antes de comenzar a trabajar, se descargará la versión completa del código de la aplicación, la denominada línea principal. En esta versión local, también llamada copia de trabajo, será sobre la que trabaje. Cuando haya concluido su tarea, probará el programa, solucionará los posibles errores y podrá volver a cargar la nueva versión en la línea principal.

No obstante, este ingeniero no trabaja solo. Mientras desarrollaba su tarea, otros integrantes del equipo han realizado las suyas y cada uno de ellos tendrá una versión diferente del software en su equipo. Asimismo, probablemente la versión de la línea principal también haya sido modificada por otros desarrolladores en este lapso de tiempo, por lo que tendrá que actualizar su copia local. Si surge algún problema, será su responsabilidad solucionarlo. A continuación, integrará el código en la línea principal y probará de nuevo el programa. Solo cuando no se vuelva a producir ningún error, lo cual podría ocurrir si no ha actualizado correctamente su copia local, habrá concluido el proceso y podrá dedicarse al desarrollo de la siguiente tarea.

Cuando se trabaja de este modo, deben acatarse una serie de reglas. En la mayoría de las ocasiones, los programadores se rigen por los principios que Martin Fowler describió para llevar a cabo con éxito una integración continua. En primer lugar, se ha de garantizar que todos los implicados se encuentran al mismo nivel, y que no hay nadie cuyo comportamiento pueda causar problemas.

Aunque parezca obvio, se trata de uno de los factores más importantes, ya que todos los integrantes del equipo deberán utilizar la misma herramienta, es decir, el mismo repositorio, cuando trabajen en el código. Y esto no solo se aplica al código fuente. Para que funcionen las aplicaciones, se necesitan otros elementos como, por ejemplo, bases de datos, que también deberán estar contenidos en el mismo lugar. Por ello, Martin Fowler recomienda construir un repositorio de tal forma que cualquier ingeniero que se incorpore al proyecto con un equipo nuevo encuentre todos los archivos necesarios en un único lugar.

La obtención de un proyecto funcional a partir de un código fuente implica la compilación del mismo, actualizar bases de datos y mover ficheros de un sitio a otro. Todas estas tareas pueden automatizarse y debería ser posible ejecutar la compilación con un único comando.

Un equipo podrá beneficiarse de aún más automatización y rapidez a través de la integración continua si se incorporan mecanismos de prueba en el proceso de compilación (“build”). Al igual que la propia compilación, las pruebas podrán llevarse a cabo en poco tiempo, y lo ideal será implementar un plan completo de mecanismos de prueba.

Un proceso de continuous integration funcionará únicamente si todos los miembros del equipo respetan el sistema. En el momento en que algún miembro del equipo no integre su código en la línea principal, el resto de compañeros partirá de una premisa falsa. Todos los desarrolladores asumen que trabajan en un sistema estable, pero si alguien tarda más de un día en integrar su código y continúa trabajando en él, al final la búsqueda de errores podría convertirse en un verdadero problema. Asimismo, la comunicación también es un factor importante en la integración continua, ya que, si los desarrolladores se mantienen al tanto, las pequeñas dificultades podrán aclararse con mayor rapidez.

El código de la línea principal deberá probarse continuamente y encontrarse siempre operativo, por lo que los desarrolladores deberán construir el proyecto aquí y no solo en su copia local. En este contexto, todos deberán preocuparse también de que sus aportaciones sean válidas y de que su funcionamiento sea correcto, de modo que todos tendrán que comprobar el código y el build. Si aparece algún fallo, tendrán que solventarlo y garantizar que el código no contiene errores.

Lo más importante de la integración continua es que no quede ninguna versión defectuosa en la línea principal, lo que implica que la solución de los fallos no podrá posponerse. En palabras de Martin Fowler, no existe ningún problema si los builds no funcionan y el código debe cambiarse, pero el sistema requiere que la reparación se lleve a cabo de inmediato. Todos los desarrolladores deben poder partir del hecho de que el código de la línea principal funciona correctamente, de lo contrario, podrían estar trabajando sobre un código defectuoso que acabará desencadenando una oleada de fallos.

La integración completa del proyecto (incluida la fase de prueba) debería realizarse lo más rápido posible. La programación extrema (extreme programming, XP) prevé solo 10 minutos para esto. Puesto que un desarrollador debe realizar varias integraciones diarias, si no se establecieran mecanismos para acelerar el proceso se perdería una gran cantidad de tiempo. Para que no se demore demasiado, debe descartarse la idea de realizar todas las pruebas posibles directamente y aplicarse en lugar de ello un sistema de dos fases: en la primera fase, se realizan pruebas en las que la compilación del proyecto pueda ser rápida. La segunda fase durará varias horas y en ella se llevarán a cabo pruebas más exhaustivas.

Las pruebas deberán realizarse en un entorno seguro y con una configuración exactamente igual que la del entorno de producción. Bajo determinadas circunstancias, esto podría resultar muy costoso, pero la virtualización de los equipos hará que el factor de los costes se reduzca.

Todos los involucrados en el desarrollo de un determinado software deberían poder obtener fácilmente el último ejecutable del programa y ejecutarlo. La implementación de este aspecto es relativamente sencilla, ya que la integración continua exige que todos los archivos se encuentren en un único repositorio que todos conocen. De este modo, se puede comenzar a realizar pruebas adicionales en el proceso de programación, los accionistas pueden utilizar archivos ejecutables con fines demostrativos y los directores de calidad pueden examinar las cifras.

No solo resulta importante que todos los implicados tengan acceso al código fuente y puedan ejecutar el archivo, sino que, además, debe quedar constancia de quién ha realizado qué modificación. Asimismo, los desarrolladores deben informar cuando se encuentren en un proceso de compilación, para lo que algunos equipos utilizan elementos visuales que indican que se está trabajando en la integración.

Por último, ha de automatizarse el despliegue del software. Para llevar a cabo la integración continua se deben mover ejecutables entre múltiples entornos, lo que puede requerir una gran cantidad de tiempo. Por ello, será mejor hacerlo de forma automática utilizando scripts que faciliten el despliegue de aplicaciones entre entornos.

A pesar de sus aspectos positivos, la integración continua ha demostrado no aportar únicamente ventajas. Sin duda, evita llevar a cabo una larga y difícil fase de integración al final del proyecto y brinda la posibilidad de poder detectar los errores a tiempo, pero puede ser muy difícil de aplicar para equipos acostumbrados a otros métodos, en cuyo caso podría incluso hacer perder más tiempo del que ahorraría.

En principio, la integración continua se puede aplicar sin necesidad de utilizar herramientas específicas, ya que todas las fases pueden llevarse a cabo de forma manual, pero esto requeriría mucho tiempo y disciplina. Con ayuda de las herramientas justas, se puede facilitar el trabajo. Estas herramientas suelen proveer un servidor y ayudan en la compilación del proyecto y en el control de versiones.

• Jenkins: este popular programa escrito en Java es una bifurcación de Hudson, que ha dejado de actualizarse. El software de código abierto funciona con distintas herramientas de compilación y sistemas de control de versiones.
• Travis CI: esta herramienta de integración continua es especialmente apreciada por su compatibilidad con GitHub, que informa a Travis de los cambios realizados en el código. Existe una versión gratuita del software para proyectos de código abierto y cuenta también con una versión de pago.
• Bamboo: con el servidor Bamboo, los desarrolladores podrán llevar a cabo la integración, el despliegue y la gestión del lanzamiento continuo. Pertenece a la empresa Atlassian y cuenta con interfaz web y tecnología Java. Bamboo supone una ayuda a los desarrolladores mediante la automatización de procesos y funciona con diferentes herramientas de compilación. Existe una versión gratuita para proyectos de código abierto.
• Gitlab CI: GitLab ofrece un programa propio de integración continua que funciona con la conocida herramienta de control de versiones. Los pipelines pueden configurarse y adaptarse así a los requisitos de cada proyecto. Además, es compatible con GitLab CI Docker.
• CircleCI: de este software existen dos versiones distintas para la integración continua. Las versiones permiten trabajar directamente en la nube o bien en un servidor local propio.
• CruiseControl: aunque fue desarrollado por ThoughtWorks (empresa relacionada con Martin Fowlers), CruiseControl ha pasado a ser un proyecto independiente. Este software libre está basado en Java y es compatible con cualquier plataforma. Entre otros, CruiseControls ofrece a los desarrolladores un panel de control (una página web propia) en el que se puede consultar el estado de los builds.
• Codeship: Codeship pretende ofrecer a los desarrolladores una opción sencilla para la integración continua. Basándose en la tecnología de contenedores, se pueden crear con él automatismos fácilmente. Para esta tarea, la compañía ofrece dos versiones diferentes: Basic y Pro.
• TeamCity: este software comercial pone mucho énfasis en la interoperabilidad con otras herramientas. Su versión estándar es compatible con numerosos programas y el espectro puede ampliarse mediante plugins. Una característica de este software son los Pre-tested commits. TeamCity comprueba el código nuevo antes de integrarlo en la línea principal e informa en caso de errores.