La in­te­gra­ción continua en el de­sa­rro­llo de software

La in­te­gra­ción plantea problemas de sobra conocidos por aquellos que se dedican al de­sa­rro­llo de software: se escribe un código nuevo que desempeña una tarea crucial, el código fuente se im­ple­me­n­ta en el proyecto y aparecen los problemas. Con el objetivo de evitar una ca­tá­s­tro­fe al final de una larga fase de de­sa­rro­llo, muchos equipos deciden aplicar la in­te­gra­ción continua (co­n­ti­nuous in­te­gra­tion en inglés), con la que los cambios se im­ple­me­n­tan todos los días di­re­c­ta­me­n­te en el proyecto, a poder ser, varias veces al día.

Al igual que la entrega continua, la in­te­gra­ción continua es una práctica muy común sobre todo en el ámbito del de­sa­rro­llo de software ágil. El objetivo de este moderno enfoque es trabajar a pasos pequeños con el fin de lograr un proceso de de­sa­rro­llo más efectivo y poder reac­cio­nar con más fle­xi­bi­li­dad antes los cambios. La in­te­gra­ción continua fue me­n­cio­na­da por primera vez en la de­fi­ni­ción de Kent Beck sobre la me­to­do­lo­gía de pro­gra­ma­ción extrema (eXtreme Pro­gra­m­mi­ng). No obstante, esta idea ya existía con an­te­rio­ri­dad y se aplicaba, por ejemplo, en el método Booch.

La in­te­gra­ción continua supone una solución para es­ce­na­rios como el siguiente: una empresa trabaja en un proyecto de gran en­ve­r­ga­du­ra, que consiste en el de­sa­rro­llo de un complejo software para un cliente. Los equipos diseñan aspectos parciales de la apli­ca­ción y los de­sa­rro­lla­do­res programan las distintas funciones. Tras varios meses o incluso años de trabajo, debe montarse y co­m­pi­lar­se 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 fra­g­me­n­tos de código y llevar el software a las fases de prueba y de­s­plie­gue.

En la in­te­gra­ción continua, el código nuevo se añade mucho antes y no cuando todos los im­pli­ca­dos han concluido su parte. Los de­sa­rro­lla­do­res 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 pro­gra­ma­do­res pueden acceder. Puesto que se trata de pequeños fra­g­me­n­tos de código, la in­te­gra­ción se realiza rá­pi­da­me­n­te y, en tan solo unos minutos, el de­sa­rro­lla­dor puede poner su trabajo a di­s­po­si­ción del resto del equipo. Si se descubre algún error en este proceso, se podrá localizar y so­lu­cio­nar rá­pi­da­me­n­te.

En la práctica, la in­te­gra­ción continua se aplica del siguiente modo: un ingeniero debe de­sa­rro­llar una función. Antes de comenzar a trabajar, se de­s­ca­r­ga­rá la versión completa del código de la apli­ca­ción, la de­no­mi­na­da 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, so­lu­cio­na­rá 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 de­sa­rro­lla­ba su tarea, otros in­te­gra­n­tes del equipo han realizado las suyas y cada uno de ellos tendrá una versión diferente del software en su equipo. Asimismo, pro­ba­ble­me­n­te la versión de la línea principal también haya sido mo­di­fi­ca­da por otros de­sa­rro­lla­do­res en este lapso de tiempo, por lo que tendrá que ac­tua­li­zar su copia local. Si surge algún problema, será su re­s­po­n­sa­bi­li­dad so­lu­cio­nar­lo. A co­n­ti­nua­ció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 ac­tua­li­za­do co­rre­c­ta­me­n­te su copia local, habrá concluido el proceso y podrá dedicarse al de­sa­rro­llo de la siguiente tarea.

Cuando se trabaja de este modo, deben acatarse una serie de reglas. En la mayoría de las ocasiones, los pro­gra­ma­do­res se rigen por los pri­n­ci­pios que Martin Fowler describió para llevar a cabo con éxito una in­te­gra­ción continua. En primer lugar, se ha de ga­ra­n­ti­zar que todos los im­pli­ca­dos se en­cue­n­tran al mismo nivel, y que no hay nadie cuyo co­m­po­r­ta­mie­n­to pueda causar problemas.

Aunque parezca obvio, se trata de uno de los factores más im­po­r­ta­n­tes, ya que todos los in­te­gra­n­tes del equipo deberán utilizar la misma he­rra­mie­n­ta, es decir, el mismo re­po­si­to­rio, cuando trabajen en el código. Y esto no solo se aplica al código fuente. Para que funcionen las apli­ca­cio­nes, se necesitan otros elementos como, por ejemplo, bases de datos, que también deberán estar co­n­te­ni­dos en el mismo lugar. Por ello, Martin Fowler re­co­mie­n­da construir un re­po­si­to­rio de tal forma que cualquier ingeniero que se incorpore al proyecto con un equipo nuevo encuentre todos los archivos ne­ce­sa­rios en un único lugar.

La obtención de un proyecto funcional a partir de un código fuente implica la co­m­pi­la­ción del mismo, ac­tua­li­zar bases de datos y mover ficheros de un sitio a otro. Todas estas tareas pueden au­to­ma­ti­zar­se y debería ser posible ejecutar la co­m­pi­la­ción con un único comando.

Un equipo podrá be­ne­fi­ciar­se de aún más au­to­ma­ti­za­ción y rapidez a través de la in­te­gra­ción continua si se in­co­r­po­ran me­ca­ni­s­mos de prueba en el proceso de co­m­pi­la­ción (“build”). Al igual que la propia co­m­pi­la­ción, las pruebas podrán llevarse a cabo en poco tiempo, y lo ideal será im­ple­me­n­tar un plan completo de me­ca­ni­s­mos de prueba.

Un proceso de co­n­ti­nuous in­te­gra­tion fu­n­cio­na­rá úni­ca­me­n­te 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 co­m­pa­ñe­ros partirá de una premisa falsa. Todos los de­sa­rro­lla­do­res 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 tra­ba­ja­n­do en él, al final la búsqueda de errores podría co­n­ve­r­ti­r­se en un verdadero problema. Asimismo, la co­mu­ni­ca­ción también es un factor im­po­r­ta­n­te en la in­te­gra­ción continua, ya que, si los de­sa­rro­lla­do­res se mantienen al tanto, las pequeñas di­fi­cu­l­ta­des podrán aclararse con mayor rapidez.

El código de la línea principal deberá probarse co­n­ti­nua­me­n­te y en­co­n­trar­se siempre operativo, por lo que los de­sa­rro­lla­do­res deberán construir el proyecto aquí y no solo en su copia local. En este contexto, todos deberán preo­cu­par­se también de que sus apo­r­ta­cio­nes sean válidas y de que su fu­n­cio­na­mie­n­to sea correcto, de modo que todos tendrán que comprobar el código y el build. Si aparece algún fallo, tendrán que so­l­ve­n­tar­lo y ga­ra­n­ti­zar que el código no contiene errores.

Lo más im­po­r­ta­n­te de la in­te­gra­ción continua es que no quede ninguna versión de­fe­c­tuo­sa en la línea principal, lo que implica que la solución de los fallos no podrá po­s­po­ne­r­se. 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 re­pa­ra­ción se lleve a cabo de inmediato. Todos los de­sa­rro­lla­do­res deben poder partir del hecho de que el código de la línea principal funciona co­rre­c­ta­me­n­te, de lo contrario, podrían estar tra­ba­ja­n­do sobre un código de­fe­c­tuo­so que acabará des­en­ca­de­na­n­do una oleada de fallos.

La in­te­gra­ción completa del proyecto (incluida la fase de prueba) debería rea­li­zar­se lo más rápido posible. La pro­gra­ma­ción extrema (extreme pro­gra­m­mi­ng, XP) prevé solo 10 minutos para esto. Puesto que un de­sa­rro­lla­dor debe realizar varias in­te­gra­cio­nes diarias, si no se es­ta­ble­cie­ran me­ca­ni­s­mos para acelerar el proceso se perdería una gran cantidad de tiempo. Para que no se demore demasiado, debe de­s­ca­r­tar­se la idea de realizar todas las pruebas posibles di­re­c­ta­me­n­te y aplicarse en lugar de ello un sistema de dos fases: en la primera fase, se realizan pruebas en las que la co­m­pi­la­ción del proyecto pueda ser rápida. La segunda fase durará varias horas y en ella se llevarán a cabo pruebas más exhau­s­ti­vas.

Las pruebas deberán rea­li­zar­se en un entorno seguro y con una co­n­fi­gu­ra­ción exac­ta­me­n­te igual que la del entorno de pro­du­c­ción. Bajo de­te­r­mi­na­das ci­r­cu­n­s­ta­n­cias, esto podría resultar muy costoso, pero la vi­r­tua­li­za­ción de los equipos hará que el factor de los costes se reduzca.

Todos los in­vo­lu­cra­dos en el de­sa­rro­llo de un de­te­r­mi­na­do software deberían poder obtener fá­ci­l­me­n­te el último eje­cu­ta­ble del programa y eje­cu­tar­lo. La im­ple­me­n­ta­ción de este aspecto es re­la­ti­va­me­n­te sencilla, ya que la in­te­gra­ción continua exige que todos los archivos se en­cue­n­tren en un único re­po­si­to­rio que todos conocen. De este modo, se puede comenzar a realizar pruebas adi­cio­na­les en el proceso de pro­gra­ma­ción, los ac­cio­ni­s­tas pueden utilizar archivos eje­cu­ta­bles con fines de­mo­s­tra­ti­vos y los di­re­c­to­res de calidad pueden examinar las cifras.

No solo resulta im­po­r­ta­n­te que todos los im­pli­ca­dos tengan acceso al código fuente y puedan ejecutar el archivo, sino que, además, debe quedar co­n­s­ta­n­cia de quién ha realizado qué mo­di­fi­ca­ción. Asimismo, los de­sa­rro­lla­do­res deben informar cuando se en­cue­n­tren en un proceso de co­m­pi­la­ción, para lo que algunos equipos utilizan elementos visuales que indican que se está tra­ba­ja­n­do en la in­te­gra­ción.

Por último, ha de au­to­ma­ti­zar­se el de­s­plie­gue del software. Para llevar a cabo la in­te­gra­ción continua se deben mover eje­cu­ta­bles entre múltiples entornos, lo que puede requerir una gran cantidad de tiempo. Por ello, será mejor hacerlo de forma au­to­má­ti­ca uti­li­za­n­do scripts que faciliten el de­s­plie­gue de apli­ca­cio­nes entre entornos.

A pesar de sus aspectos positivos, la in­te­gra­ción continua ha de­mo­s­tra­do no aportar úni­ca­me­n­te ventajas. Sin duda, evita llevar a cabo una larga y difícil fase de in­te­gra­ción al final del proyecto y brinda la po­si­bi­li­dad de poder detectar los errores a tiempo, pero puede ser muy difícil de aplicar para equipos aco­s­tu­m­bra­dos a otros métodos, en cuyo caso podría incluso hacer perder más tiempo del que ahorraría.

En principio, la in­te­gra­ción continua se puede aplicar sin necesidad de utilizar he­rra­mie­n­tas es­pe­cí­fi­cas, ya que todas las fases pueden llevarse a cabo de forma manual, pero esto re­que­ri­ría mucho tiempo y di­s­ci­pli­na. Con ayuda de las he­rra­mie­n­tas justas, se puede facilitar el trabajo. Estas he­rra­mie­n­tas suelen proveer un servidor y ayudan en la co­m­pi­la­ción del proyecto y en el control de versiones.

• Jenkins: este popular programa escrito en Java es una bi­fu­r­ca­ción de Hudson, que ha dejado de ac­tua­li­zar­se. El software de código abierto funciona con distintas he­rra­mie­n­tas de co­m­pi­la­ción y sistemas de control de versiones.
• Travis CI: esta he­rra­mie­n­ta de in­te­gra­ción continua es es­pe­cia­l­me­n­te apreciada por su co­m­pa­ti­bi­li­dad con GitHub, que informa a Travis de los cambios rea­li­za­dos 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 de­sa­rro­lla­do­res podrán llevar a cabo la in­te­gra­ción, el de­s­plie­gue y la gestión del la­n­za­mie­n­to continuo. Pertenece a la empresa Atlassian y cuenta con interfaz web y te­c­no­lo­gía Java. Bamboo supone una ayuda a los de­sa­rro­lla­do­res mediante la au­to­ma­ti­za­ción de procesos y funciona con di­fe­re­n­tes he­rra­mie­n­tas de co­m­pi­la­ción. Existe una versión gratuita para proyectos de código abierto.
• Gitlab CI: GitLab ofrece un programa propio de in­te­gra­ción continua que funciona con la conocida he­rra­mie­n­ta de control de versiones. Los pipelines pueden co­n­fi­gu­rar­se y adaptarse así a los re­qui­si­tos de cada proyecto. Además, es co­m­pa­ti­ble con GitLab CI Docker.
• CircleCI: de este software existen dos versiones distintas para la in­te­gra­ción continua. Las versiones permiten trabajar di­re­c­ta­me­n­te en la nube o bien en un servidor local propio.
• Crui­se­Co­n­trol: aunque fue de­sa­rro­lla­do por Thou­gh­t­Wo­r­ks (empresa re­la­cio­na­da con Martin Fowlers), Crui­se­Co­n­trol ha pasado a ser un proyecto in­de­pe­n­die­n­te. Este software libre está basado en Java y es co­m­pa­ti­ble con cualquier pla­ta­fo­r­ma. Entre otros, Crui­se­Co­n­tro­ls ofrece a los de­sa­rro­lla­do­res 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 de­sa­rro­lla­do­res una opción sencilla para la in­te­gra­ción continua. Basándose en la te­c­no­lo­gía de co­n­te­ne­do­res, se pueden crear con él au­to­ma­ti­s­mos fá­ci­l­me­n­te. Para esta tarea, la compañía ofrece dos versiones di­fe­re­n­tes: Basic y Pro.
• TeamCity: este software comercial pone mucho énfasis en la in­te­ro­pe­ra­bi­li­dad con otras he­rra­mie­n­tas. Su versión estándar es co­m­pa­ti­ble con numerosos programas y el espectro puede ampliarse mediante plugins. Una ca­ra­c­te­rí­s­ti­ca de este software son los Pre-tested commits. TeamCity comprueba el código nuevo antes de in­te­grar­lo en la línea principal e informa en caso de errores.