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.
La integración continua es una práctica del desarrollo de software ágil en la que los ingenieros van integrando los fragmentos de código que desarrollan poco a poco en lugar de hacerlo una vez concluido todo el proyecto.
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.
Para que la administración de una herramienta de este tipo funcione correctamente, se necesita un control de versiones. La utilización del software adecuado facilitará el trabajo y mantendrá a todos los participantes informados.
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.
El método ágil de desarrollo guiado por pruebas (test driven development, TDD) confiere mucha importancia a la fase de testing. Sin embargo, según Martin Fowler, no es necesario implementar un TDD completo para trabajar con integración continua.
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.
| Ventajas | Inconvenientes |
|---|---|
| Detección temprana de errores | Cambio de procesos habituales |
| Comunicación constante | Precisa servidores y entornos adicionales |
| Evita una integración final de gran envergadura | Elaboración de un plan de pruebas propio |
| Registro exacto de las modificaciones | Puede derivar en demoras cuando varios desarrolladores intentan integrar sus códigos al mismo tiempo |
| Disponibilidad constante de una versión funcional y actualizada | |
| Fomenta el trabajo minucioso |
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.
En nuestro artículo de profundización encontrarás más información sobre las ventajas e inconvenientes de las diferentes herramientas de integración continua.
Las herramientas de integración continua facilitan el trabajo diario de los desarrolladores. Si quieres implementar los actuales métodos ágiles de desarrollo de software, como la integración continua, deberás contar con mucho tiempo y disciplina o bien hacer uso de herramientas de integración continua. Estas herramientas resultan útiles para la automatización de procesos. Te presentamos las más...
Continous delivery consiste en una serie de prácticas que permiten a los desarrolladores de software automatizar el proceso de desarrollo, control de calidad, ejecución de pruebas, producción y entrega. Gracias a este, es posible entregar el software al cliente, aunque se encuentre en una fase temprana de desarrollo. Te contamos cuáles son exactamente, qué ventajas aportan y qué continuous...
Los dos paradigmas de programación elementales, el imperativo y el declarativo, son los dos estilos de programación fundamentales. No se trata, por tanto, de “estilos de programación” de programadores individuales, sino de enfoques técnicos diferentes a la hora de escribir programas. En este artículo presentamos los paradigmas de software y sus subtipos.
Cada vez más empresas de desarrollo de software implementan DevOps, una moderna metodología que renueva la estructura empresarial y promete procesos más rápidos y sencillos, así como una mejora en la comunicación y el trabajo en equipo. No te pierdas las ventajas, las desventajas y los diversos ámbitos de aplicación de este sistema.
El éxito de la programación de software depende del modelo de desarrollo y, por tanto, es esencial elegir el más adecuado para satisfacer los requerimientos. Además, de esta forma es posible minimizar los costes de desarrollo a largo plazo. Así es como una comparación entre Continuous Integration vs. Continuous Delivery vs. Continuous Deployment te mostrará que modelo es el más adecuado para tus...
Ofrece un servicio fiable y de alto rendimiento a tus clientes con un pack hosting de IONOS.
Ver planes
