Close

¿En qué consiste la integración continua?

Crea una metodología ágil para tu equipo con un feedback más rápido. Porque solo avanzas tan rápido como tus pruebas.


La integración continua (CI) es la práctica de automatizar la integración de los cambios de código de varios contribuidores en un único proyecto de software. Es una de las principales prácticas recomendadas de DevOps, que permite a los desarrolladores fusionar con frecuencia los cambios de código en un repositorio central donde luego se ejecutan las compilaciones y pruebas. Las herramientas automatizadas sirven para verificar que el nuevo código es correcto antes de la integración.

Un sistema de control de versiones del código fuente es el punto clave del proceso de CI. El sistema de control de versiones también se complementa con otras comprobaciones como las pruebas automatizadas de calidad del código, las herramientas de revisión de estilo de sintaxis y mucho más.

Cómo poner en marcha la integración continua

Descubre cómo adoptar la integración continua y las pruebas automatizadas en cinco pasos. Leer el artículo

Cinco consejos para repositorios de Git compatibles con CI

Cinco consejos para sacarle todo el partido a Git y a tu herramienta de integración continua. Leer el artículo

Herramientas de integración continua

Cinco consejos para sacarle todo el partido a Git y a tu herramienta de integración continua. Leer el artículo

Desarrollo basado en troncos

Descubre qué es el desarrollo basado en troncos, una práctica de control de versiones en la que los desarrolladores fusionan pequeñas actualizaciones de forma frecuente en un "tronco" o rama principal. Leer el artículo

Tutorial sobre integración continua

En este tutorial, verás cómo empezar con la integración continua en tres sencillos pasos. Probar el tutorial


La importancia de la integración continua

Para entender la importancia de la CI, nos viene bien hablar primero de algunos puntos problemáticos que surgen a menudo por la falta de esta. Sin la CI, los desarrolladores tienen que coordinarse y comunicarse manualmente cuando aportan código al producto final. Esta coordinación va más allá de los equipos de desarrollo; llega también a los equipos de operaciones y al resto de la organización. Los equipos de producto tienen que coordinar cuándo lanzar funciones y soluciones secuencialmente, y qué miembros del equipo serán los responsables.

Los gastos generales de comunicación de un entorno sin CI pueden convertirse en una tarea de sincronización compleja y confusa, que añade costes administrativos innecesarios a los proyectos. Esto provoca publicaciones de código más lentas con una mayor tasa de fallo, puesto que los desarrolladores tienen que ser sensibles y considerados en lo que respecta a las integraciones. Los riesgos crecen exponencialmente a medida que crecen los tamaños del equipo de ingeniería y la base de código.

Sin una canalización de CI sólida, puede crearse una desconexión entre el equipo de ingeniería y el resto de la organización. La comunicación entre el equipo de producto y el de ingeniería puede ser engorrosa. La ingeniería se convierte en una caja negra en la que el resto del equipo solicita requisitos y funciones, y a lo mejor obtiene los resultados esperados. Hace más difícil para los ingenieros estimar el tiempo de la entrega de las solicitudes, porque el tiempo para integrar los nuevos cambios se convierte en un riesgo desconocido.

Qué hace la IC

La IC ayuda a escalar el resultado de plantilla y entrega de los equipos de ingeniería. Si se introduce la IC en el escenario mencionando anteriormente, los desarrolladores de software pueden trabajar independientemente en las funciones de forma paralela. Cuando estén listos para fusionar estas funciones en el producto final, lo pueden hacer de forma independiente y rápida. La IC es una práctica valiosa y bien establecida en las organizaciones de ingeniería de software modernas y de alto rendimiento.

Cómo se utiliza la CI

La CI se utiliza generalmente junto con un flujo de trabajo de desarrollo de software de metodología ágil. Una organización compilará una lista de tareas que constituyan una hoja de ruta de productos. A continuación, estas tareas se distribuyen entre los miembros del equipo de ingeniería de software para la entrega. Al utilizar la CI, estas tareas de desarrollo de software pueden desarrollarse independientemente y en paralelo entre los desarrolladores asignados. Una vez que una de estas tareas esté completa, un desarrollador introducirá el nuevo trabajo en el sistema de CI para integrarlo con el resto del proyecto.

CI, implementación continua y entrega continua

La integración, implementación y entrega continuas son tres fases de una canalización de publicación de software automatizada, incluida una canalización de DevOps. Estas tres fases llevan el software de la idea a la entrega y al usuario final. La fase de integración es el primer paso en el proceso. La integración continua abarca el proceso de varios desarrolladores intentando fusionar sus cambios de código con el repositorio de código principal de un proyecto.

La entrega continua es la siguiente extensión de la integración continua. La fase de entrega se encarga de empaquetar un artefacto para entregarlo a los usuarios finales. Esta fase ejecuta herramientas de compilación automatizadas para generar el artefacto. Esta fase de compilación se mantiene “verde”, lo que significa que el artefacto debería estar listo para su implementación a los usuarios en cualquier momento.

La implementación continua es la fase final de la canalización. La fase de implementación se encarga de lanzar y distribuir automáticamente el artefacto de software a los usuarios finales. En el momento de la implementación, el artefacto ha superado correctamente las fases de integración y entrega. Ahora es el momento de implementar o distribuir automáticamente el artefacto. Esto se producirá mediante scripts o herramientas que mueven automáticamente el artefacto a servidores públicos o a otro mecanismo de distribución, como una tienda de aplicaciones.


Ventajas y retos de la integración continua

La integración continua es un aspecto esencial de DevOps y los equipos de software de alto rendimiento. Sin embargo, las ventajas de la CI no se limitan al equipo de ingeniería, sino que benefician enormemente a toda la organización. La CI permite una mejor transparencia e información sobre el proceso de desarrollo y entrega de software. Estas ventajas permiten que el resto de la organización planifique mejor y ejecute estrategias de lanzamiento al mercado. A continuación, se exponen algunas de las ventajas organizativas generales de la CI.

Permite el escalado

La CI permite que las organizaciones escalen en tamaño del equipo de ingeniería, tamaño de la base de código e infraestructura. Al minimizar los procesos de integración de código y los gastos generales de comunicación, la CI ayuda a desarrollar flujos de trabajo de metodología ágil y DevOps. Permite que cada miembro del equipo sea el responsable de un nuevo cambio de código hasta la publicación. La CI permite el escalado al eliminar las dependencias organizativas entre el desarrollo de las funciones individuales. Los desarrolladores ahora pueden trabajar en las funciones en una unidad aislada y tener la garantía de que su código se integrará a la perfección con el resto de la base de código, que es un proceso fundamental de DevOps.

Mejora el ciclo de feedback

Un feedback más rápido para las decisiones empresariales es otro efecto colateral potente de la CI. Los equipos de producto pueden probar las ideas e iterar los diseños del producto más rápido con una plataforma de CI optimizada. Los cambios pueden notificarse rápidamente y medir su éxito. Los errores u otras incidencias pueden abordarse rápidamente y resolverse.

Mejora la comunicación

La CI mejora la comunicación general de ingeniería y la rendición de cuentas, lo que permite una mayor colaboración entre el desarrollo y las operaciones en un equipo de DevOps. Al introducir flujos de trabajo de solicitudes de extracción ligados a la CI, los desarrolladores comparten el conocimiento pasivo. Las solicitudes de extracción permiten a los desarrolladores observar y comentar el código de otros miembros del equipo. Los desarrolladores ahora pueden ver las ramas de funcionalidades y colaborar en ellas con otros desarrolladores a medida que las funciones progresan por la canalización de CI. La CI también sirve para ayudar a controlar el gasto de recursos de control de calidad. Una canalización de CI eficaz con cobertura de pruebas automatizadas de gran confianza te protegerá de regresiones y garantizará que las nuevas funciones cumplan una especificación. Antes de que se fusione el nuevo código, debe superar el conjunto de aserción de pruebas de CI que evitará cualquier nueva regresión.

Las ventajas de la CI superan con creces cualquier reto en su adopción. Dicho esto, es importante ser consciente de los retos de la CI. Los retos reales de la CI surgen al mover un proyecto de no CI a CI. Los proyectos de software más modernos adoptarán la CI desde las fases tempranas y así se aliviarán los retos de la adopción más tardía.

Adopción e instalación

Los retos de la integración continua se concentran principalmente en la adopción del equipo y la instalación técnica inicial. Si el equipo actualmente no tiene una solución de CI implementada, elegir una y empezar puede suponer un cierto esfuerzo. Por lo tanto, al instalar una canalización de CI, deben tomarse una serie de consideraciones sobre la infraestructura de ingeniería existente.

Curva de aprendizaje de la tecnología

Las funciones de CI vienen con una lista de tecnologías de apoyo que pueden suponer una inversión de curva de aprendizaje para el equipo. Estas tecnologías son los sistemas de control de versiones, la infraestructura de alojamiento y las tecnologías de orquestación.


Prácticas recomendadas de CI

Desarrollo basado en pruebas

Una vez que un proyecto haya establecido un pipeline de IC con cobertura de pruebas automáticas, una práctica recomendada consiste en desarrollar y mejorar constantemente la cobertura de pruebas. Cada nueva función que atraviese el pipeline de IC debe ir con un conjunto de pruebas para comprobar que el nuevo código se comporta como se espera.

El desarrollo basado en pruebas (TDD) es la práctica de escribir el código de prueba y los casos de prueba antes de hacer cualquier codificación de funciones real. El TDD puro puede involucrar estrechamente al equipo de producto para ayudar a moldear una especificación de comportamiento empresarial esperado, que después puede transformarse en casos de prueba. En un escenario de TDD puro, los desarrolladores y el equipo de producto se reunirán y discutirán una especificación o una lista de requisitos. A continuación, esta lista de requisitos se convertirá en una checklist de aserciones de código. Entonces los desarrolladores escribirán código que cumpla estas aserciones.

Solicitudes de incorporación de cambios y revisión de código

La mayoría de los equipos de desarrollo de software modernos siguen un flujo de trabajo de solicitud de extracción y revisión de código. Las solicitudes de extracción son una práctica esencial para una CI eficaz y se crean cuando un desarrollador está listo para fusionar nuevo código en la base de código principal. Además, se encargan de notificar a los otros desarrolladores del nuevo conjunto de cambios que están listos para la integración.

Las solicitudes de extracción son el momento oportuno para iniciar la canalización de CI y ejecutar el conjunto de pasos de aprobación automatizados. Normalmente se añade un paso de aprobación adicional y manual en el momento de la solicitud de extracción, durante el que un ingeniero que no es una parte interesada realiza una revisión de código de la función. Así, el nuevo código y función pasan por un par de ojos diferentes. Este ingeniero realizará sugerencias de edición y aprobará o denegará la solicitud de extracción.

Las solicitudes de extracción y la revisión de código son una herramienta potente para fomentar la comunicación pasiva y el intercambio de conocimiento entre el equipo de ingeniería. Esto ayuda a proteger frente a la deuda técnica en forma de unidades aisladas de conocimiento, donde los ingenieros específicos son las únicas partes interesadas para algunas funciones de base de código.

Optimiza la velocidad de la canalización

Dado que el pipeline de IC va a ser un proceso central y usado con frecuencia, es importante optimizar su velocidad de ejecución. Un pequeño retraso en el flujo de trabajo de IC se agravará exponencialmente a medida que crezca la tasa de publicaciones de funciones, el tamaño del equipo y el tamaño del código base. Medir la velocidad del pipeline de IC y optimizarla como sea necesario se trata de una práctica recomendada.

Un pipeline de IC más rápido permite un ciclo de feedback de productos más rápido. Los desarrolladores pueden notificar los cambios rápidamente y experimentar con nuevas ideas para funciones para mejorar la experiencia de usuario. Cualquier solución de error se puede aplicar rápidamente y resolver cuando se descubra. La mayor velocidad de ejecución puede ofrecer tanto una ventaja frente a la competencia como una experiencia general de mayor calidad para tus clientes.


Primeros pasos con la integración continua

La dependencia básica de la IC es un sistema de control de versiones (VCS). Si la base de código objetivo para una instalación de IC no tiene un VCS, el primer paso es instalarlo. La ausencia de un VCS debería ser muy poco frecuente en las bases de código modernas. Algunos VCS populares son Git, Mercurial y Subversion.

Una vez que el control de versiones esté implementado, encontrar una plataforma de alojamiento de control de versiones es el siguiente paso. La mayoría de herramientas de alojamiento de control de versiones modernas cuentan con soporte y funciones integradas para IC. Algunas plataformas de alojamiento de control de versiones populares son Bitbucket, Github y Gitlab.

Una vez establecido el control de versiones en el proyecto, deben añadirse pasos de aprobación de integración. El paso de aprobación de integración más valioso que implementar son las pruebas automatizadas. Añadir pruebas automatizadas a un proyecto puede tener gastos generales iniciales. Se tiene que instalar un marco de pruebas y después los desarrolladores deben escribir código de prueba y casos de prueba.

Los comprobadores de sintaxis, los formateadores de estilo de código o los exámenes de vulnerabilidades de dependencias son algunas ideas de otros mecanismos de aprobación de IC menos caros que puedes añadir. Una vez que tengas un sistema de control de versiones instalado con algunos pasos de aprobación de fusiones, habrás establecido la integración continua.

La IC no es un proceso empresarial puramente específico de la ingeniería. El resto de la organización (los equipos de marketing, ventas y producto) también se beneficiarán de un pipeline de IC. Los equipos de producto tendrán que pensar cómo simultanear la ejecución de flujos de desarrollo paralelos. Los equipos de producto e ingeniería trabajarán codo con codo para determinar las expectativas de funciones empresariales aplicables que formarán el conjunto de pruebas automatizado.

Los equipos de marketing y ventas podrán consultar la canalización de CI para coordinarse con los eventos y esfuerzos de comunicación orientados a los clientes. La CI le da un nivel de transparencia al resto de la organización sobre cómo la ejecución de la ingeniería está progresando. Esta función de transparencia y comunicación se integra sin problemas con un flujo de trabajo de desarrollo de proyectos de metodología ágil.


En conclusión...

Si tu organización se esfuerza por cosechar los beneficios de un enfoque de DevOps o simplemente tiene un equipo de software de varios desarrolladores, la CI resulta importante. La CI ayudará al equipo de ingeniería a funcionar de forma más rápida y eficaz.

La CI es un elemento habitual de las organizaciones de desarrollo de software modernas de alto rendimiento. Las mejores empresas cuentan con pipelines de IC sólidos y no se lo piensan dos veces a la hora de invertir para ganar eficacia. Los beneficios de la IC no se limitan al equipo de ingeniería y se aplican a toda la organización.

Existen muchas herramientas de terceros para ayudar en la administración e instalación de CI. Algunas opciones populares son Codeship, Bitbucket Pipelines, Semaphore CI, CircleCI, Jenkins, Bamboo, TeamCity y muchas otras. Estas herramientas tienen sus propias guías de instalación y documentación exhaustivas para ayudarte a dar los primeros pasos.

Prueba algunas de las mejores herramientas de CI que proporciona Atlassian:

Bitbucket Pipelines es una gran utilidad para conseguir que un proyecto vaya sobre ruedas con funciones de CI modernas.

Jira es una de las herramientas de gestión de proyectos de metodología ágil y DevOps más populares del mundo. Se integra estrechamente con otros proyectos de Bitbucket y, cuando se une a una canalización de CI, puede ofrecer una visión muy transparente del estado de ejecución de una organización.

Max Rehkopf
Max Rehkopf

Como persona caótica que soy, confío en las prácticas de la metodología ágil y en los principios optimizados para poner orden en mi día a día. Me alegra compartir estas lecciones con otras personas a través de los muchos artículos, ponencias y vídeos que hago para Atlassian. 


Lecturas recomendadas

Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.

Ilustración de Devops

La comunidad de DevOps

Ilustración de Devops

Leer el blog

Ilustración de un mapa

Pruébalo gratis

Suscríbete para recibir el boletín de DevOps

Thank you for signing up