Los procesos de CI / CD son una de las mejores prácticas que deben implementar los equipos de devops, para entregar cambios de código con mayor frecuencia y confiabilidad, y es una de las prácticas que tiene la factoría de software de BLMovil.
La integración continua (CI) y el despliegue continuo (CD) incorporan una cultura, un conjunto de principios operativos y una colección de buenas prácticas que permiten a los equipos de desarrollo entregar cambios el en código con mayor frecuencia y confiabilidad. La implementación también se conoce como pipeline 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 las metodologías ágiles, ya que permite a los equipos de desarrollo de software centrarse en cumplir los requisitos comerciales, la calidad del código y la seguridad porque los pasos de implementación están automatizados.
Cómo definir CI / CD
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 subir el código a los repositorios de control de versiones con frecuencia. Debido a que la mayoría de las aplicaciones que se desarrollan en la actualidad se desarrollan con código de diferentes plataformas y herramientas, el equipo necesita un mecanismo para integrar y validar sus cambios.
El objetivo técnico de la Integración Coninua es establecer una forma coherente y automatizada de crear, empaquetar y probar aplicaciones. Al hacerlo con consistencia en el proceso de integración, es más probable que los equipos realicen cambios de código con mayor frecuencia, lo que termina llevando a dichos equipos a una mejor colaboración y finalmente a una mayor calidad del software.
El Despliegue Continuo comienza donde termina la integración continua. El Despliegue Continuo (CD) automatiza el despliegue de aplicaciones a diferentes entornos de infraestructura. La mayoría de los equipos trabajan con varios entornos distintos a los de producción, como los entornos de desarrollo y pruebas, y el Despliegue Continuo 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 los 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.
El objetivo técnico de la Integración Continua es establecer una forma coherente y automatizada de crear, empaquetar y probar aplicaciones. Con la consistencia del proceso de integración, es más probable que los equipos realicen cambios de código con mayor frecuencia, lo que conduce a una mejor colaboración y calidad del software.
Una práctica madura de DevOps de CI / CD tiene la opción de implementar despliegue continuo donde los cambios en las aplicaciones se ejecutan a través de pipelines CI / CD y las compilaciones exitosas se despliegan directamente en los entornos de producción. Los equipos que dentro de sus prácticas implementan el despliegue continuo, pueden llegar a desplegar en producción en una planificación diaria o incluso por horas, aunque hay que tener en cuenta que el despliegue continuo no siempre es la solución óptima para cualquier tipo de aplicación.
Cómo mejora la Integración Continua la colaboración y la calidad
La Integración Continua es una filosofía de desarrollo respaldada por una mecánica de procesos y cierta automatización asociada a la misma. Al utilizar la Integración Continua, los programadores envían su código al repositorio de control de versiones de forma frecuente y la mayoría de los equipos de desarrollo tienen un estándar mínimo de confirmación de código al menos diariamente. El motivo de esto es que es más fácil identificar cualquier defecto que pueda existir y cualquier otro problema de calidad del software en diferenciales de código más pequeños que en los proyectos más grandes que se desarrollan durante un período más extenso de tiempo. Además, cuando los programadores trabajan en ciclos de desarrollos más cortos, es menos probable que varios programadores editen el mismo código y requieran una fusión en código común al realizar la subida del código al repositorio de control de versiones.
Los equipos de desarrollo que implementan la Integración Continua suelen comenzar con la configuración del control de versiones y las definiciones de las mejores prácticas. Aunque la subidas del código se realiza con frecuencia, las funciones y las correcciones se implementan en períodos de tiempo cortos y 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 flags de características, 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 marcan con flags 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 flags de características indican que tienen mejores procesos de prueba y realizan un software de mayor calidad. Las herramientas de flags de características como CloudBees Rollout, Optimizely Rollouts y LaunchDarkly se pueden integrar con herramientas CI / CD y permiten configuraciones a nivel de función.
Otra técnica para administrar características es la ramificación del control de versiones. Se selecciona una estrategia de ramificación como Gitflow para definir protocolos sobre cómo el nuevo código se fusiona en ramas estándar para desarrollo, prueba y producción. Se crean ramas con 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í mismo se automatiza empaquetando todo el software, la base de datos y otros componentes. Por ejemplo, si estuviera desarrollando una aplicación Java, la Integración Continua empaquetaría todos los archivos del servidor web estático, como HTML, CSS y JavaScript, junto con la aplicación Java y cualquier script de base de datos.
La Integración Continua 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. Estas pruebas van a indicar a los programadores de que sus cambios en el 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, desencadenadas 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 funcione para el 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 obstaculizar el progreso de los equipos que intentan codificar rápidamente y comprometerse a entregas con frecuencia como indican las metodologías ágiles.
Las pruebas continuas van más allá de la automatización de pruebas
Los frameworks de prueba automatizados ayudan a los responsables de control de calidad a definir, ejecutar y automatizar varios tipos de pruebas que van a ayudar a los equipos de programación a saber si una compilación de software pasa o falla. Incluyen pruebas funcionales que se desarrollan al final de cada sprint y que posteriormente se agregan a una prueba de regresión para toda la aplicación. Estas pruebas de regresión van a poder informar al equipo si un cambio en el código falló en una o más de las pruebas desarrolladas en todas las áreas funcionales de la aplicación cubiertas por las pruebas de regresión.
Una práctica recomendada es habilitar y exigir a los programadores que ejecuten todas o un subconjunto de las pruebas de regresión en sus entornos locales. Este paso garantiza que los programadores 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 en su entorno local.
Las pruebas de regresión son solo unas de las pruebas a automatizar. Se pueden automatizar también las pruebas de rendimiento, las pruebas del API, el análisis de código estático, las pruebas de seguridad y otros tipos de prueba adicionales. 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 el pipeline de CI / CD. Se pueden integrar algunas pruebas unitarias y funcionales en la Integración Contuinua para indicar problemas antes o durante el proceso de integración. Las pruebas que necesitan de un entorno completo para desplegarse, como las pruebas de rendimiento y seguridad, se suelen integrar en los procesos de Integración Continua y se ejecutan después de que las compilaciones se despliegan en los entornos correspondientes.
El pipeline de Despliegue Continuo automatiza los cambios en múltiples entornos
El Despliegue Conntinuo es la automatización que implementa las aplicaciones a los diferentes entornos. La mayoría de los equipos de desarrollo suelen tener uno o más entornos de desarrollo y prueba en los que se depliegan los cambios de las aplicaciones para ejecutar las pruebas y revisar su fucionamiento. Para ello 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 sobr eel proceso.
Un Ppeline de CD típico tiene etapas de compilación, prueba e implementación. Los pipelines más complejos 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 bajar la infraestructura de la nube.
- Mover código al entorno de destino.
- Gestionar las variables de entorno y configurarlas para el entorno de destino.
- Desplegar los componentes de la aplicación en sus correspondientes servicios, como servidores web, servicios API y servidores de base 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 despliegues de código.
- Ejecución de pruebas continuas y entornos de rollback si fallan las pruebas.
- Almacenar los logs del proceso y alertas sobre el estado del despliegue.
Por ejemplo ejemplo, los usuarios de Jenkins definen sus pipelines en un archivo Jenkins que describe diferentes etapas, como compilación, prueba e implementación. Las variables de entorno, las opciones, las claves secretas, las 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 condiciones de error y 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 disponer de un market de complementos. Por ejemplo, Jenkins dispone de más de 1.500 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 reporting y un panel de control. Si fallan las compliaciones o los despliegues, van a alertar a los programadores con información sobre los errores. Estas herramientas se integran con el control de versiones y las con las herramientas ágiles, por lo que se pueden utilizar para buscar qué cambios de código e historias de usuario componen una compilación.
Implementación de pipelines de CI / CD con Kubernetes y arquitecturas sin servidor
Muchos equipos que operan pipelines de CI / CD en entornos en la nube también utilizan contenedores como Docker y sistemas de orquestación como Kubernetes. Los contenedores permiten empaquetar y desplegar aplicaciones de una forma estándar y portable. 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 pipelines de CI / CD juntos. Se pueden explorar las diferentes opciones investigando integraciones 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 en función de 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 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 tuvieron fallos en las pruebas unitarias. CD es la automatización que ofrece cambios a la infraestructura y ejecuta pruebas adicionales.
Los pipelines de CI / CD están diseñados para las empresas que modifican las aplicaciones con frecuencia y requieren un proceso de entrega confiable. El esfuerzo adicional para estandarizar las compilaciones, automatizar las pruebas y los despliegues es lo que va a facilitar el proceso de fabricación para implementar cambios de código. Una vez realizado, permite a los equipos centrarse más en el proceso de mejora de las aplicaciones y menos en los detalles del sistema para desplegarlo en los diferentes entornos.
CI / CD es una de las mejores prácticas de DevOps porque implica que no hace falta tener alineados a los programadores que desean desplegar cambios con frecuencia, con los equipos de operaciones que lo que quieren son aplicaciones y sistemas estables estables. Con la implementación de la automatización, los programadores pueden desplegar cambios con más frecuencia y 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 pipelines 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, van a mejorar bastante 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 despliegue.
Comenzar con CI / CD implica que los equipos de desarrollo y los equipos de operación 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 esté implementado CI / CD , el equipo lo aplique de manera consistente.