¿Qué es CI / CD? Integración continua y la entrega continua

119

La canalización de CI / CD es una de las mejores prácticas que deben implementar los equipos de devops, para entregar cambios de código con mayor frecuencia y confiabilidad.

La integración continua (CI) y la entrega continua (CD) incorporan una cultura, un conjunto de principios operativos y una colección de prácticas que permiten a los equipos de desarrollo de aplicaciones entregar cambios de código con mayor frecuencia y confiabilidad. La implementación también se conoce como canalización CI / CD .

CI / CD es una de las mejores prácticas que pueden implementar los equipos de devops . También es una práctica recomendada de metodología ágil , ya que permite a los equipos de desarrollo de software centrarse en cumplir con los requisitos comerciales, la calidad del código y la seguridad porque los pasos de implementación están automatizados.

CI / CD definido

La integración continua  es una filosofía de codificación y un conjunto de prácticas que impulsan a los equipos de desarrollo a implementar pequeños cambios y verificar el código en los repositorios de control de versiones con frecuencia. Debido a que la mayoría de las aplicaciones modernas requieren el desarrollo de código en diferentes plataformas y herramientas, el equipo necesita un mecanismo para integrar y validar sus cambios.

El objetivo técnico de CI es establecer una forma coherente y automatizada de crear, empaquetar y probar aplicaciones. Con la coherencia en el proceso de integración, es más probable que los equipos realicen cambios de código con más frecuencia, lo que conduce a una mejor colaboración y calidad del software.

La entrega continua  comienza donde termina la integración continua. CD automatiza la entrega de aplicaciones a entornos de infraestructura seleccionados. La mayoría de los equipos trabajan con múltiples entornos además de la producción, como los entornos de desarrollo y prueba, y el CD garantiza que haya una forma automatizada de enviarles cambios de código.

Las herramientas de CI / CD ayudan a almacenar los parámetros específicos del entorno que se deben empaquetar con cada entrega. La automatización de CI / CD luego realiza las llamadas de servicio necesarias a servidores web, bases de datos y otros servicios que pueden necesitar reiniciarse o seguir otros procedimientos cuando se implementan las aplicaciones.

La integración continua y la entrega continua requieren  pruebas continuas  porque el objetivo es entregar aplicaciones y código de calidad a los usuarios. Las pruebas continuas a menudo se implementan como un conjunto de pruebas de regresión, rendimiento y otras pruebas automatizadas que se ejecutan en la canalización de CI / CD.

Una práctica madura de DevOps de CI / CD tiene la opción de implementar una implementación continua donde los cambios de aplicación se ejecutan a través de la canalización de CI / CD y las compilaciones pasadas se implementan directamente en los entornos de producción. Los equipos que practican la entrega continua eligen implementar la producción en un programa diario o incluso por horas, aunque la entrega continua no siempre es óptima para todas las aplicaciones comerciales.

Cómo la integración continua mejora la colaboración y la calidad

La integración continua es una filosofía de desarrollo respaldada por la mecánica de procesos y cierta automatización. Al practicar la CI, los desarrolladores envían su código al repositorio de control de versiones con frecuencia y la mayoría de los equipos tienen un estándar mínimo de confirmación de código al menos a diario. La razón de ser de esto es que es más fácil identificar defectos y otros problemas de calidad del software en diferenciales de código más pequeños que en los más grandes desarrollados durante un período extenso de tiempo. Además, cuando los desarrolladores trabajan en ciclos de confirmación más cortos, es menos probable que varios desarrolladores editen el mismo código y requieran una fusión al realizar la confirmación.

Los equipos que implementan la integración continua a menudo comienzan con la configuración del control de versiones y las definiciones de práctica. Aunque la verificación del código se realiza con frecuencia, las funciones y las correcciones se implementan tanto en períodos de tiempo cortos como más largos. Los equipos de desarrollo que practican la integración continua utilizan diferentes técnicas para controlar qué funciones y código están listos para la producción.

Muchos equipos utilizan marcas de funciones , un mecanismo de configuración para activar o desactivar funciones y código en tiempo de ejecución. Las características que aún están en desarrollo se envuelven con indicadores de características en el código, se implementan con la rama maestra a producción y se apagan hasta que estén listas para usarse. Según una encuesta reciente , el 63 por ciento de los equipos que usan marcas de funciones informan mejores pruebas y software de mayor calidad. Las herramientas de marcado de características como CloudBees Rollout , Optimizely Rollouts y LaunchDarkly se integran con herramientas CI / CD y permiten configuraciones a nivel de función.

Otra técnica para administrar funciones es la  ramificación de control de versiones . Se selecciona una estrategia de ramificación como Gitflow para definir protocolos sobre cómo se fusiona el nuevo código en ramas estándar para desarrollo, prueba y producción. Se crean ramas de características adicionales para aquellas que requerirán ciclos de desarrollo más largos. Cuando la función está completa, los desarrolladores pueden fusionar los cambios de las ramas de funciones en la rama de desarrollo principal. Este enfoque funciona bien, pero puede resultar difícil de administrar si se desarrollan muchas funciones al mismo tiempo.

El proceso de construcción en sí se automatiza luego empaquetando todo el software, la base de datos y otros componentes. Por ejemplo, si estuviera desarrollando una aplicación Java, CI empaquetaría todos los archivos del servidor web estático, como HTML, CSS y JavaScript, junto con la aplicación Java y los scripts de la base de datos.

CI no solo empaqueta todo el software y los componentes de la base de datos, sino que la automatización también ejecutará pruebas unitarias y otras pruebas. Esta prueba proporciona comentarios a los desarrolladores de que sus cambios de código no rompieron ninguna prueba unitaria existente.

La mayoría de las herramientas de CI / CD permiten a los desarrolladores iniciar compilaciones bajo demanda, activadas por confirmaciones de código en el repositorio de control de versiones o en un horario definido. Los equipos deben analizar el programa de compilación que mejor se adapte al tamaño del equipo, la cantidad de confirmaciones diarias esperadas y otras consideraciones de la aplicación. Una mejor práctica para garantizar que las confirmaciones y las compilaciones sean rápidas; de lo contrario, puede impedir el progreso de los equipos que intentan codificar rápidamente y comprometerse con frecuencia.

Las pruebas continuas van más allá de la automatización de pruebas

Los marcos de prueba automatizados ayudan a los ingenieros de control de calidad a definir, ejecutar y automatizar varios tipos de pruebas que pueden ayudar a los equipos de desarrollo a saber si una compilación de software pasa o falla. Incluyen pruebas de funcionalidad que se desarrollan al final de cada sprint y se agregan a una prueba de regresión para toda la aplicación. Estas pruebas de regresión luego informan al equipo si un cambio de código falló en una o más de las pruebas desarrolladas en todas las áreas funcionales de la aplicación donde hay cobertura de prueba.

Una práctica recomendada es habilitar y exigir a los desarrolladores que ejecuten todas o un subconjunto de las pruebas de regresión en sus entornos locales. Este paso garantiza que los desarrolladores solo envíen el código al control de versiones después de que las pruebas de regresión pasen los cambios de código.

Las pruebas de regresión son solo el comienzo. Las pruebas de rendimiento, las pruebas de API, el análisis de código estático, las pruebas de seguridad y otras formas de prueba también se pueden automatizar. La clave es poder activar estas pruebas a través de la línea de comandos, webhook o servicio web y que respondan con códigos de estado de éxito o error.

Una vez que las pruebas están automatizadas, las pruebas continuas implican que la automatización está integrada en la canalización de CI / CD. Algunas pruebas unitarias y de funcionalidad se pueden integrar en CI que señalan problemas antes o durante el proceso de integración. Las pruebas que requieren un entorno de entrega completo, como las pruebas de rendimiento y seguridad, a menudo se integran en el CD y se realizan después de que las compilaciones se entregan a los entornos de destino.

La canalización de CD automatiza los cambios en múltiples entornos

La entrega continua es la automatización que empuja las aplicaciones a los entornos de entrega. La mayoría de los equipos de desarrollo suelen tener uno o más entornos de desarrollo y prueba en los que los cambios de las aplicaciones se preparan para probar y revisar. Se utiliza una herramienta de CI / CD como Jenkins , CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo o Travis CI para automatizar los pasos y proporcionar informes.

Una canalización de CD típica tiene etapas de construcción, prueba e implementación. Las canalizaciones más sofisticadas incluyen muchos de estos pasos:

  • Extraer código del control de versiones y ejecutar una compilación.
  • Ejecutar cualquier paso de infraestructura requerido que esté automatizado como código para levantar o derribar la infraestructura de la nube.
  • Mover código al entorno informático de destino.
  • Gestionar las variables de entorno y configurarlas para el entorno de destino.
  • Empujar los componentes de la aplicación a sus servicios apropiados, como servidores web, servicios API y servicios de bases de datos.
  • La ejecución de los pasos necesarios para reiniciar los servicios o llamar a los puntos finales del servicio que se necesitan para los nuevos impulsos de código.
  • Ejecución de pruebas continuas y entornos de reversión si las pruebas fallan.
  • Proporcionar datos de registro y alertas sobre el estado de la entrega.

A modo de ejemplo, los usuarios de Jenkins definen sus canalizaciones en un archivo Jenkins que describe diferentes etapas, como compilación, prueba e implementación. Las variables de entorno, opciones, claves secretas, certificaciones y otros parámetros se declaran en el archivo y luego se hace referencia a ellos por etapas. La sección de publicaciones maneja las condiciones de error y las notificaciones.

Los CD más sofisticados pueden tener otros pasos, como realizar sincronizaciones de datos, archivar recursos de información o realizar parches de aplicaciones y bibliotecas. Las herramientas de CI / CD suelen admitir un mercado de complementos. Por ejemplo,  Jenkins enumera más de 1500 complementos que admiten la integración con plataformas de terceros, interfaz de usuario, administración, gestión de código fuente y gestión de compilación.

Una vez que se selecciona una herramienta de CI / CD, los equipos de desarrollo deben asegurarse de que todas las variables de entorno estén configuradas fuera de la aplicación. Las herramientas de CI / CD permiten configurar estas variables, enmascarar variables como contraseñas y claves de cuenta, y configurarlas en el momento de la implementación para el entorno de destino.

Las herramientas de CD también proporcionan funciones de informes y panel de control. Si fallan las construcciones o las entregas, alertan a los desarrolladores con información sobre las fallas. Se integran con el control de versiones y las herramientas ágiles, por lo que se pueden usar para buscar qué cambios de código e historias de usuario conformaron una compilación.

Implementación de canalizaciones de CI / CD con Kubernetes y arquitecturas sin servidor

Muchos equipos que operan canalizaciones de CI / CD en entornos de nube también utilizan contenedores como Docker y sistemas de orquestación como  Kubernetes . Los contenedores permiten aplicaciones de embalaje y envío de forma estándar y portátil. Los contenedores facilitan la ampliación o la eliminación de entornos que tienen cargas de trabajo variables.

Hay muchos enfoques para usar contenedores, infraestructura como código y canalizaciones de CI / CD juntos. Puede explorar las opciones trabajando con tutoriales como Kubernetes con Jenkins o Kubernetes con Azure DevOps .

Las arquitecturas de computación sin servidor presentan otra vía para implementar y escalar aplicaciones. En un entorno sin servidor, la infraestructura está completamente administrada por el proveedor de servicios en la nube y la aplicación consume recursos según sea necesario según su configuración. En AWS, por ejemplo, las aplicaciones sin servidor se ejecutan como funciones Lambda y las implementaciones se pueden integrar en una canalización de Jenkins CI / CD con un complemento.

CI / CD permite implementaciones de código más frecuentes

En resumen, los paquetes de CI y las compilaciones de software de pruebas y alertan a los desarrolladores si sus cambios fallaron en las pruebas unitarias. CD es la automatización que ofrece cambios en la infraestructura y ejecuta pruebas adicionales.

Las canalizaciones de CI / CD están diseñadas para empresas que desean mejorar las aplicaciones con frecuencia y requieren un proceso de entrega confiable. El esfuerzo adicional para estandarizar compilaciones, desarrollar pruebas y automatizar implementaciones es el proceso de fabricación para implementar cambios de código. Una vez en su lugar, permite a los equipos centrarse en el proceso de mejora de las aplicaciones y menos en los detalles del sistema para entregarlo a los entornos informáticos.

CI / CD es una de las mejores prácticas de DevOps porque aborda la desalineación entre los desarrolladores que desean impulsar cambios con frecuencia, con operaciones que desean aplicaciones estables. Con la automatización implementada, los desarrolladores pueden impulsar cambios con más frecuencia. Los equipos de operaciones ven una mayor estabilidad porque los entornos tienen configuraciones estándar, hay pruebas continuas en el proceso de entrega, las variables de entorno están separadas de la aplicación y los procedimientos de reversión están automatizados.

El impacto de la implementación de canalizaciones de CI / CD se puede medir como un indicador clave de rendimiento (KPI) de DevOps . Los KPI, como la frecuencia de implementación, el tiempo de espera del cambio y el tiempo medio de recuperación (MTTR) de un incidente, a menudo mejoran cuando se implementa CI / CD con pruebas continuas. Sin embargo, CI / CD es solo un proceso que puede impulsar estas mejoras, y existen otros requisitos previos para mejorar las frecuencias de implementación.

Comenzar con CI / CD requiere que los equipos de desarrollo y los equipos operativos colaboren en tecnologías, prácticas y prioridades. Los equipos deben desarrollar un consenso sobre los enfoques correctos para sus negocios y tecnologías, de modo que una vez que CI / CD esté en su lugar, el equipo esté a bordo con las siguientes prácticas de manera consistente.