Integración Continua

¿Qué es la integración continua?

Como muchos otros procedimientos de la metodología ágil una de las funciones principales de la CI (Integración Continua) es facilitar el trabajo al desarrollador.

Cuando hablamos de integración contínua, nos referimos a la creación de código entre diferentes desarrolladores y bajo una minuciosa comprobación del mismo. Para hacer que esto sea posible y fácil, no se espera a que el código esté finalizado, como se hacía en los métodos convencionales o de cascada, sino que se llega a dividir el trabajo en pequeñas tareas,también denominadas sprints, que no suponen un gran esfuerzo ni se necesita una gran inversión de tiempo, de forma que se puedan ir comprobando dichas tareas frecuentemente.

Definición

Es el proceso automatizado para ensamblar y probar versiones ejecutables del software, de manera que el equipo de desarrollo pueda construir y probar varias veces al día el software en la que se está trabajando.

Este concepto es conocido como “integración continua” y es una de las prácticas de Extreme Programming, sin embargo no es necesario estar siguiendo Extreme Programming para aplicarla.

La integración continua es una práctica de desarrollo que requiere que los desarrolladores integren el código en un repositorio compartido varias veces al día. Cada registro se verifica luego mediante una compilación automatizada, lo que permite a los equipos detectar problemas en una etapa temprana. Al integrarse regularmente, puede detectar errores rápidamente y localizarlos más fácilmente.

Debe tomar Nota: Cuando se habla de “integrar” software, esto se refiere al proceso específico de generar una versión ejecutable de un software, que puede involucrar compilar el código fuente, empaquetar, incluir archivos de configuración, etc.

Características

Como muchos otros procedimientos de la metodología ágil una de las funciones principales de la Integración Continua, según Duvall, Matyas, y Glover (2007), cuando se habla de integración contínua, se refiere a la creación de código entre diferentes desarrolladores y bajo una minuciosa comprobación del mismo. Para hacer que esto sea posible y fácil, no se espera a que el código esté finalizado, como se hacía en los métodos convencionales o de cascada, sino que se llega a dividir el trabajo en pequeñas tareas, también denominadas sprints, que no suponen un gran esfuerzo ni se necesita una gran inversión de tiempo, de forma que se puedan ir comprobando dichas tareas frecuentemente. Estas comprobaciones se deben llevar a cabo por lo menos una vez al día y suelen ser realizadas al finalizar cada jornada laboral. En base a los resultados, se puede seguir creando o entrando en la fase de modificación, donde una vez detectado el error, el grupo decidirá cómo se puede superar y para ello, que deben modificar.

Ágil implica trabajar de forma rápida e intentar reducir el rango de errores al mínimo posible. Una forma de poder conseguirlo es fomentando el trabajo en equipo, de forma que se ayuden para superar las trabas y aprendan los unos de los otros.

Otra característica es desglosar los grandes proyectos en pequeñas tareas, de forma que el trabajo se mucho más llevadero, la presión menor y los tiempos de entrega/validación, más frecuentes.

Por lo tanto, un flujo continuo de revisiones, opiniones, pruebas, retroalimentación entre el cliente y entre los miembros del equipo, superación de errores, cuidar el código y trabajar cómodo hace que este tipo de prácticas sean tan frecuente hoy en día. Ahora es posible que un trabajo sea más eficiente y rentable.

Importancia de la integración continua

Beck (1998) realizó una publicación donde puso énfasis en la importancia que implica el cumplimiento del objetivo del desarrollo de las aplicaciones modernas, contando con múltiples desarrolladores que trabajen de forma simultánea en distintas funciones de la misma aplicación. Sin embargo, si una organización fusiona todo el código fuente diversificado en un solo día (conocido como el ”día de la fusión”), las tareas resultantes pueden ser tediosas y manuales, y pueden tomar mucho tiempo.

Esto sucede porque, cuando un desarrollador trabaja de forma aislada para implementar un cambio en una aplicación, existe la posibilidad de que este cambio entre en conflicto con otros cambios implementados simultáneamente por otros desarrolladores. La integración continua ayuda a que los desarrolladores fusionen los cambios que introducen en el código para incorporarlos a una división compartida (o rama) con más frecuencia, incluso diariamente. Una vez que se fusionan los cambios implementados por un desarrollador en una aplicación, se validan con el desarrollo automático de la aplicación y la ejecución de distintos niveles de pruebas automatizadas (generalmente, pruebas de unidad e integración) para verificar que los cambios no hayan dañado la aplicación.

Esto significa probar todo, desde las clases y el funcionamiento hasta los distintos módulos que conforman toda la aplicación. Si una prueba automática detecta un conflicto entre el código nuevo y el existente, la CI facilita la resolución de esos errores con frecuencia y rapidez.

Sistema de integración continua

Para que un sistema de integración continua sea eficiente, hay ciertas prácticas que debemos llevar a cabo:

• Mantener un repositorio de una única fuente.
• Automatizar las construcciones de un proyecto.
• Hacer que el proyecto ejecute sus propios exámenes.
• Todos los miembros del proyecto hacen commit a una rama principal todos los días.
• Todos los cometidos a la rama principal ejecutan una compilación.
• Las construcciones erróneas deben arreglarse inmediatamente.
• Realizar la construcción lo más rápido posible.
• Hacer pruebas en una copia del escenario de producción real.
• Despliegue continuo.

¿Qué es la entrega continua?

La entrega continua (CD) lleva el principio de CI un paso más allá según Wallgren, A. (2016). Es el proceso automatizado de compilación y prueba que extiende a todos los componentes de la aplicación, incluidos los archivos de configuración, los esquemas de base de datos y los entornos. Cada vez que se realizan cambios en cualquiera de estos componentes, el procedimiento de compilación y prueba se realiza (idealmente a través de una canalización automatizada) para que la compilación resultante se pueda implementar fácilmente. La compilación resultante no siempre tiene que publicarse en producción, pero al menos debe implementarse en un entorno (como la organización por etapas) lo más cercano posible a la producción. Por lo tanto, los propietarios del producto pueden estar seguros de que cualquier compilación que pase por este conducto sea liberado para el público.

Control de versiones

El trabajo del desarrollador es el código. Este código es compartido y almacenado de forma segura generalmente con uso de herramientas. Llamamos a este tipo de herramienta de control de versión según Typical CI process (pepgotesting, 2019) porque no solo almacena de forma segura el código, y permite a los desarrolladores compartir el código y colaborar juntos como un equipo en el mismo código, sino también versiones del código. Esto significa que cada vez que un desarrollador agrega algún código, no reemplaza la versión anterior, sino que agrega un cambio en el historial. De esa manera, los desarrolladores pueden desordenar y pueden volver fácilmente a una versión anterior. También pueden investigar problemas y comprender lo que sucedió en el código mirando la historia.

GitFlow

GitFlow es un modelo de ramificación según Scot Chacon(2009), El modelo de GitFlow es ideal para una integración continua. La idea es asegurarse de que cada vez que una rama de función se fusione para desarrollarse, la integración continua comprueba que todo está correcto en esta rama principal.

Este control se realiza regularmente. Dependiendo del contexto del proyecto y de la madurez del equipo, esta comprobación se puede realizar solo una vez al día o cada vez que un desarrollador realice un cambio único.

Ramas

Básicamente, lo que estamos hablando se llama branches en la terminología de control de versiones. Una de estas branches tiene un significado especial, representa lo que está en producción y cuál es la última versión actual. Todo el código generado se sube a una de las ramas y a menudo se llama (aunque no siempre) la rama master para generar el deploy.

Cuando los desarrolladores crean una nueva característica, no trabajan directamente en esta rama, la crean en otra diferente donde se interactúa.

Ramas principales

El repositorio central tiene dos ramas principales con una vida infinita:

• Master (por defecto y en producción).
• Develop (en desarrollo).

Ramas de apoyo

A diferencia de las ramas principales, estas ramas siempre tienen un tiempo de vida limitado, ya que eventualmente se eliminarán.

• Feature branches(Ramas destacadas)
• Release branches(Ramas de liberación)
• Hotfix branches (Ramas Hotfix)

Merge

Es el término fusionar en la sección anterior a una sola rama, por lo general la rama nueva se integra al master.

Ventajas de la integración continua

La integración continua proporciona varias ventajas o beneficios en el desarrollo de software las cuales se mencionan a continuación:

• Fácilmente deducible, el nombre que adquiere esta práctica es descriptivo y literal. Se basa en la comprobación continua del código para poder integrar poco a poco las mejoras o ir actualizando a diario para obtener un resultado mucho más fiable y en periodo menor de tiempo. Lo que permite ajustar mejor a los timings propuestos y evitar las presiones derivadas de última hora por la presión de las entregas.
• Aptitud a nivel personal. Puesto que estas prácticas se llevan a cabo en proyectos conjuntos, son los propios desarrolladores los que van analizando el código creado, apoyándose los unos en los otros. Los mismos aprenderán diferentes métodos de integración y se ven obligados a superar día tras día diferentes errores o fallos encontrados en el código creado. Esto implica fomentar la comunicación entre el equipo, y hace que sea mucho más enriquecedor tanto a nivel individual como a nivel de grupo o equipo.
• Acelerar la detección de fallas ,versión constante para pruebas, o una primera fase para poder contrastar la evolución del código de forma que haga posible detectar los errores a tiempo y poder corregirlos.
• A su vez, en todo momento cada miembro del equipo tiene acceso a la versión final.
• La integración continua garantiza unos resultados de calidad y un funcionamiento correcto del proyecto gracias a su continua supervisión y a la reducción de errores.
• Evidentemente todo este proceso de revisiones y correcciones lo más frecuentes posibles, forman parte de una automatización que se desarrolla para facilitar la comunicación entre el equipo y la evolución del proyecto el cual disminuye el lapso de tiempo dedicado a depurar errores.
• Evitar la espera para averiguar si un código funciona para esto el monitoreo de las métricas más relevantes del proyecto, de forma que se pueda tener presente en todo momento la calidad del mismo. Esto a la larga, llevará a un buen código sin necesidad de modificaciones una vez llevado a la última fase, puesto que se logra optimizar a medida que se lo construye.

En resumen, los beneficios de la integración continua consisten en “resolver problemas rápidamente”. Dado que el software es integrado frecuentemente, cuando se encuentra un error típicamente no es necesario retroceder mucho para descubrir donde se introdujo la falla. En comparación, cuando un equipo no sigue una estrategia de integración continua los periodos entre integración son largos y la base de código es muy distinta entre cada integración por lo que cuando se encuentran errores hay que revisar mucho más código, lo cual requiere un mayor tiempo y esfuerzo. En palabras de Fowler (2009), “la integración continua no elimina los defectos, pero si hace que sea mucho más fácil encontrarlos y corregirlos”.

Desventajas de la integración continua

• Complejidad en manejo de las herramientas, esto implica un coste en la capacitación del personal o del equipo dado esto conlleva tiempo adicional en el desarrollo.
• Costes de hardware, para ello es necesario un conjunto de máquinas que albergarán las diversas herramientas para la integración continua: repositorio, automatización, entornos, etc.
• Tiempo de configuración inicial, en un entorno en el que se diseñan, desarrollan y documentan adecuadamente los casos de prueba, nos queda invertir el tiempo oportuno en la configuración de la herramientas de integración continua.
• Cambio de procesos habituales.
• Precisa de servidores y entornos adicionales.
• Podría derivar en demoras cuando varios desarrolladores intentan integrar sus códigos al mismo tiempo.

Bibliografía
Adanza, F. (2016), Implementing continuous delivery: Jenkins or Bamboo. Disponible en: https://www.getzephyr.com/insights/implementing-continuous-delivery-jenkins-or-bamboo(04 Junio 2017)

Apache Maven (2019). Disponible en https://maven.apache.org/guides/index.htm

Atlassian, (n.d.), Understanding the Bamboo CI Server, Disponible en: https://confluence.atlassian.com/bamboo/understanding-the-bamboo-ci-server289277285.html (04 Junio 2017)

Beck, K. (1998, March). Extreme programming: A humanistic discipline of software development. In International Conference on Fundamental Approaches to Software Engineering (pp. 1-6). Springer, Berlin, Heidelberg.

Carlos Blé Jurado(2016) Diseño Ágil con TDD.

Continuous Integration (2019). Disponible en: http://danielcoding.net/tag/continuous-integration/

Docker (2019). Disponible en https://docs.docker.com/

Fowler, M., Beck, K., Brant, and J. (2009) Refactoring: Improving the Design of Existing Code.

Gitlab (2019). Disponible en https://about.gitlab.com/product/continuous-integration/

GIT, GitFlow and Continuous Integration for Dummies (2019). Disponible en: https://jp-lambert.me/git-gitflow-and-continuous-integration-for-dummies-5e4300148fbf (20 Julio 2019)

Gómez-Luna, E., & Fernando-Navas, D., & Aponte-Mayor, G., & Betancourt-Buitrago.

How To Orchestrate DevOps Tools Together To Solve Our Problems? (2019). Disponible en: https://www.edureka.co/blog/devops-tools/ (20 Julio 2019)

L. (2014). Metodología para la revisión bibliográfica y la gestión de información de temas científicos, a través de su estructuración y sistematización. Dyna, 81 (184), 158-163.

Jenkins 1.396 released, The first release of Jenkins is posted, Kohsuke Kawaguchi.

Jez Humble and David Farley (2011). Continuous Delivery. Disponible en

https://martinfowler.com/books/continuousDelivery.htm

Jgarzas (2014, 18 de octubre). Ph.D. en informática, Postdoctorate en la Carnegie

Mellon (EE.UU) e Ingeniero en Informática.

Martin Fowler (2006, 1 de Mayo). Continuous Integration. Disponible en: https://martinfowler.com/articles/continuousIntegration.html

Nexus (2019). Disponible en: https://help.sonatype.com/integrations/nexus-and-continuous-integration

P. M. Duvall, S. Matyas, and A. Glover (2007) Continuous integration: improving software quality and reducing risk. Pearson Education.

Scot Chacon. Pro Git. (2009).

Sneha Kunja, S. (2017), What is Jenkins?. Disponible en:https://vmokshagroup.com/blog/what-is-jenkins/ (04 Junio 2017)

Sonarqube (2019). Disponible en: https://docs.sonarqube.org/latest

Stafford, J. (n.d.), Why automated continuous integration is a must for microservices success. Disponible en: http://searchmicroservices.techtarget.com/feature/Why-automated-continuousintegration-is-a-must-for-microservices-success (03 Junio 2017)

Typical CI process, (04 Junio 2019) Disponible: www.pepgotesting.com

Wallgren, A. (2016), Continuous Delivery and Release Automation for Microservices, Disponible en: http://electric-cloud.com/blog/2016/01/continuous-delivery-and-release-automation-formicroservices/ (03 Junio 2017)