Los procesos de CI \/ CD son una de las mejores pr\u00e1cticas que deben implementar los equipos de devops, para entregar cambios de c\u00f3digo con mayor frecuencia y confiabilidad, y es una de las pr\u00e1cticas que tiene la factor\u00eda de software de BLMovil.<\/p>\n\n\n\n
La integraci\u00f3n continua (CI) y el despliegue continuo (CD) incorporan una cultura, un conjunto de principios operativos y una colecci\u00f3n de buenas pr\u00e1cticas que permiten a los equipos de desarrollo entregar cambios el en c\u00f3digo con mayor frecuencia y confiabilidad. La implementaci\u00f3n tambi\u00e9n se conoce como pipeline CI \/ CD.<\/p>\n\n\n\n
CI \/ CD es una de las mejores pr\u00e1cticas que pueden implementar los equipos de devops. Tambi\u00e9n es una pr\u00e1ctica recomendada de las metodolog\u00edas \u00e1giles, ya que permite a los equipos de desarrollo de software centrarse en cumplir los requisitos comerciales, la calidad del c\u00f3digo y la seguridad porque los pasos de implementaci\u00f3n est\u00e1n automatizados.<\/p>\n\n\n\n
La integraci\u00f3n continua es una filosof\u00eda de codificaci\u00f3n y un conjunto de pr\u00e1cticas que impulsan a los equipos de desarrollo a implementar peque\u00f1os cambios y subir el c\u00f3digo a los repositorios de control de versiones con frecuencia. Debido a que la mayor\u00eda de las aplicaciones que se desarrollan en la actualidad se desarrollan con c\u00f3digo de diferentes plataformas y herramientas, el equipo necesita un mecanismo para integrar y validar sus cambios.<\/p>\n\n\n\n
El objetivo t\u00e9cnico de la Integraci\u00f3n Coninua es establecer una forma coherente y automatizada de crear, empaquetar y probar aplicaciones. Al hacerlo con consistencia en el proceso de integraci\u00f3n, es m\u00e1s probable que los equipos realicen cambios de c\u00f3digo con mayor frecuencia, lo que termina llevando a dichos equipos a una mejor colaboraci\u00f3n y finalmente a una mayor calidad del software.<\/p>\n\n\n\n
El Despliegue Continuo comienza donde termina la integraci\u00f3n continua. El Despliegue Continuo (CD) automatiza el despliegue de aplicaciones a diferentes entornos de infraestructura. La mayor\u00eda de los equipos trabajan con varios entornos distintos a los de producci\u00f3n, como los entornos de desarrollo y pruebas, y el Despliegue Continuo garantiza que haya una forma automatizada de enviarles cambios de c\u00f3digo.<\/p>\n\n\n\n
Las herramientas de CI \/ CD ayudan a almacenar los par\u00e1metros espec\u00edficos del entorno que se deben empaquetar con cada entrega. La automatizaci\u00f3n 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.<\/p>\n\n\n\n
La integraci\u00f3n continua y la entrega continua requieren pruebas continuas porque el objetivo es entregar aplicaciones y c\u00f3digo de calidad a los usuarios. Las pruebas continuas a menudo se implementan como un conjunto de pruebas de regresi\u00f3n, rendimiento y otras pruebas automatizadas que se ejecutan en la canalizaci\u00f3n de CI \/ CD. <\/p>\n\n\n\n
El objetivo t\u00e9cnico de la Integraci\u00f3n Continua es establecer una forma coherente y automatizada de crear, empaquetar y probar aplicaciones. Con la consistencia del proceso de integraci\u00f3n, es m\u00e1s probable que los equipos realicen cambios de c\u00f3digo con mayor frecuencia, lo que conduce a una mejor colaboraci\u00f3n y calidad del software.<\/p>\n\n\n\n
Una pr\u00e1ctica madura de DevOps de CI \/ CD tiene la opci\u00f3n de implementar despliegue continuo donde los cambios en las aplicaciones se ejecutan a trav\u00e9s de pipelines CI \/ CD y las compilaciones exitosas se despliegan directamente en los entornos de producci\u00f3n. Los equipos que dentro de sus pr\u00e1cticas implementan el despliegue continuo, pueden llegar a desplegar en producci\u00f3n en una planificaci\u00f3n diaria o incluso por horas, aunque hay que tener en cuenta que el despliegue continuo no siempre es la soluci\u00f3n \u00f3ptima para cualquier tipo de aplicaci\u00f3n.<\/p>\n\n\n\n
La Integraci\u00f3n Continua es una filosof\u00eda de desarrollo respaldada por una mec\u00e1nica de procesos y cierta automatizaci\u00f3n asociada a la misma. Al utilizar la Integraci\u00f3n Continua, los programadores env\u00edan su c\u00f3digo al repositorio de control de versiones de forma frecuente y la mayor\u00eda de los equipos de desarrollo tienen un est\u00e1ndar m\u00ednimo de confirmaci\u00f3n de c\u00f3digo al menos diariamente. El motivo de esto es que es m\u00e1s f\u00e1cil identificar cualquier defecto que pueda existir y cualquier otro problema de calidad del software en diferenciales de c\u00f3digo m\u00e1s peque\u00f1os que en los proyectos m\u00e1s grandes que se desarrollan durante un per\u00edodo m\u00e1s extenso de tiempo. Adem\u00e1s, cuando los programadores trabajan en ciclos de desarrollos m\u00e1s cortos, es menos probable que varios programadores editen el mismo c\u00f3digo y requieran una fusi\u00f3n en c\u00f3digo com\u00fan al realizar la subida del c\u00f3digo al repositorio de control de versiones.<\/p>\n\n\n\n
Los equipos de desarrollo que implementan la Integraci\u00f3n Continua suelen comenzar con la configuraci\u00f3n del control de versiones y las definiciones de las mejores pr\u00e1cticas. Aunque la subidas del c\u00f3digo se realiza con frecuencia, las funciones y las correcciones se implementan en per\u00edodos de tiempo cortos y m\u00e1s largos. Los equipos de desarrollo que practican la integraci\u00f3n continua utilizan diferentes t\u00e9cnicas para controlar qu\u00e9 funciones y c\u00f3digo est\u00e1n listos para la producci\u00f3n.<\/p>\n\n\n\n
Muchos equipos utilizan flags de caracter\u00edsticas, un mecanismo de configuraci\u00f3n para activar o desactivar funciones y c\u00f3digo en tiempo de ejecuci\u00f3n. Las caracter\u00edsticas que a\u00fan est\u00e1n en desarrollo se marcan con flags de caracter\u00edsticas en el c\u00f3digo, se implementan con la rama maestra a producci\u00f3n y se apagan hasta que est\u00e9n listas para usarse. Seg\u00fan una encuesta reciente, el 63 por ciento de los equipos que usan flags de caracter\u00edsticas indican que tienen mejores procesos de prueba y realizan un software de mayor calidad. Las herramientas de flags de caracter\u00edsticas como CloudBees Rollout, Optimizely Rollouts y LaunchDarkly se pueden integrar con herramientas CI \/ CD y permiten configuraciones a nivel de funci\u00f3n.<\/p>\n\n\n\n
Otra t\u00e9cnica para administrar caracter\u00edsticas es la ramificaci\u00f3n del control de versiones. Se selecciona una estrategia de ramificaci\u00f3n como Gitflow para definir protocolos sobre c\u00f3mo el nuevo c\u00f3digo se fusiona en ramas est\u00e1ndar para desarrollo, prueba y producci\u00f3n. Se crean ramas con caracter\u00edsticas adicionales para aquellas que requerir\u00e1n ciclos de desarrollo m\u00e1s largos. Cuando la funci\u00f3n est\u00e1 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\u00edcil de administrar si se desarrollan muchas funciones al mismo tiempo.<\/p>\n\n\n\n
El proceso de construcci\u00f3n en s\u00ed mismo se automatiza empaquetando todo el software, la base de datos y otros componentes. Por ejemplo, si estuviera desarrollando una aplicaci\u00f3n Java, la Integraci\u00f3n Continua empaquetar\u00eda todos los archivos del servidor web est\u00e1tico, como HTML, CSS y JavaScript, junto con la aplicaci\u00f3n Java y cualquier script de base de datos.<\/p>\n\n\n\n
La Integraci\u00f3n Continua no solo empaqueta todo el software y los componentes de la base de datos, sino que la automatizaci\u00f3n tambi\u00e9n ejecutar\u00e1 pruebas unitarias y otras pruebas. Estas pruebas van a indicar a los programadores de que sus cambios en el c\u00f3digo no rompieron ninguna prueba unitaria existente.<\/p>\n\n\n\n
La mayor\u00eda de las herramientas de CI \/ CD permiten a los desarrolladores iniciar compilaciones bajo demanda, desencadenadas por confirmaciones de c\u00f3digo en el repositorio de control de versiones o en un horario definido. Los equipos deben analizar el programa de compilaci\u00f3n que mejor funcione para el tama\u00f1o del equipo, la cantidad de confirmaciones diarias esperadas y otras consideraciones de la aplicaci\u00f3n. Una mejor pr\u00e1ctica para garantizar que las confirmaciones y las compilaciones sean r\u00e1pidas; de lo contrario, puede obstaculizar el progreso de los equipos que intentan codificar r\u00e1pidamente y comprometerse a entregas con frecuencia como indican las metodolog\u00edas \u00e1giles.<\/p>\n\n\n\n
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\u00f3n a saber si una compilaci\u00f3n 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\u00f3n para toda la aplicaci\u00f3n. Estas pruebas de regresi\u00f3n van a poder informar al equipo si un cambio en el c\u00f3digo fall\u00f3 en una o m\u00e1s de las pruebas desarrolladas en todas las \u00e1reas funcionales de la aplicaci\u00f3n cubiertas por las pruebas de regresi\u00f3n.<\/p>\n\n\n\n
Una pr\u00e1ctica recomendada es habilitar y exigir a los programadores que ejecuten todas o un subconjunto de las pruebas de regresi\u00f3n en sus entornos locales. Este paso garantiza que los programadores solo env\u00eden el c\u00f3digo al control de versiones despu\u00e9s de que las pruebas de regresi\u00f3n pasen los cambios de c\u00f3digo en su entorno local.<\/p>\n\n\n\n
Las pruebas de regresi\u00f3n son solo unas de las pruebas a automatizar. Se pueden automatizar tambi\u00e9n las pruebas de rendimiento, las pruebas del API, el an\u00e1lisis de c\u00f3digo est\u00e1tico, las pruebas de seguridad y otros tipos de prueba adicionales. La clave es poder activar estas pruebas a trav\u00e9s de la l\u00ednea de comandos, webhook o servicio web y que respondan con c\u00f3digos de estado de \u00e9xito o error.<\/p>\n\n\n\n
Una vez que las pruebas est\u00e1n automatizadas, las pruebas continuas implican que la automatizaci\u00f3n est\u00e1 integrada en el pipeline de CI \/ CD. Se pueden integrar algunas pruebas unitarias y funcionales en la Integraci\u00f3n Contuinua para indicar problemas antes o durante el proceso de integraci\u00f3n. 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\u00f3n Continua y se ejecutan despu\u00e9s de que las compilaciones se despliegan en los entornos correspondientes.<\/p>\n\n\n\n
El Despliegue Conntinuo es la automatizaci\u00f3n que implementa las aplicaciones a los diferentes entornos. La mayor\u00eda de los equipos de desarrollo suelen tener uno o m\u00e1s 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.<\/p>\n\n\n\n
Un Ppeline de CD t\u00edpico tiene etapas de compilaci\u00f3n, prueba e implementaci\u00f3n. Los pipelines m\u00e1s complejos incluyen muchos de estos pasos:<\/p>\n\n\n\n
Por ejemplo ejemplo, los usuarios de Jenkins definen sus pipelines en un archivo Jenkins que describe diferentes etapas, como compilaci\u00f3n, prueba e implementaci\u00f3n. Las variables de entorno, las opciones, las claves secretas, las certificaciones y otros par\u00e1metros se declaran en el archivo y luego se hace referencia a ellos por etapas. La secci\u00f3n de publicaciones maneja condiciones de error y notificaciones.<\/p>\n\n\n\n
Los CD m\u00e1s sofisticados pueden tener otros pasos, como realizar sincronizaciones de datos, archivar recursos de informaci\u00f3n 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\u00e1s de 1.500 complementos que admiten la integraci\u00f3n con plataformas de terceros, interfaz de usuario, administraci\u00f3n, gesti\u00f3n de c\u00f3digo fuente y gesti\u00f3n de compilaci\u00f3n.<\/p>\n\n\n\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\u00e9n configuradas fuera de la aplicaci\u00f3n. Las herramientas de CI \/ CD permiten configurar estas variables, enmascarar variables como contrase\u00f1as y claves de cuenta, y configurarlas en el momento de la implementaci\u00f3n para el entorno de destino.<\/p>\n\n\n\n
Las herramientas de CD tambi\u00e9n proporcionan funciones de reporting y un panel de control. Si fallan las compliaciones o los despliegues, van a alertar a los programadores con informaci\u00f3n sobre los errores. Estas herramientas se integran con el control de versiones y las con las herramientas \u00e1giles, por lo que se pueden utilizar para buscar qu\u00e9 cambios de c\u00f3digo e historias de usuario componen una compilaci\u00f3n.<\/p>\n\n\n\n
Muchos equipos que operan pipelines de CI \/ CD en entornos en la nube tambi\u00e9n utilizan contenedores como Docker y sistemas de orquestaci\u00f3n como Kubernetes. Los contenedores permiten empaquetar y desplegar aplicaciones de una forma est\u00e1ndar y portable. Los contenedores facilitan la ampliaci\u00f3n o la eliminaci\u00f3n de entornos que tienen cargas de trabajo variables.<\/p>\n\n\n\n
Hay muchos enfoques para usar contenedores, infraestructura como c\u00f3digo y pipelines de CI \/ CD juntos. Se pueden explorar las diferentes opciones investigando integraciones como Kubernetes con Jenkins o Kubernetes con Azure DevOps.<\/p>\n\n\n\n
Las arquitecturas de computaci\u00f3n sin servidor presentan otra v\u00eda para implementar y escalar aplicaciones. En un entorno sin servidor, la infraestructura est\u00e1 completamente administrada por el proveedor de servicios en la nube y la aplicaci\u00f3n consume recursos seg\u00fan sea necesario en funci\u00f3n de su configuraci\u00f3n. En AWS, por ejemplo, las aplicaciones sin servidor se ejecutan como funciones Lambda y las implementaciones se pueden integrar en una canalizaci\u00f3n Jenkins CI \/ CD con un complemento.<\/p>\n\n\n\n
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\u00f3n que ofrece cambios a la infraestructura y ejecuta pruebas adicionales.<\/p>\n\n\n\n
Los pipelines de CI \/ CD est\u00e1n dise\u00f1ados 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\u00f3n para implementar cambios de c\u00f3digo. Una vez realizado, permite a los equipos centrarse m\u00e1s en el proceso de mejora de las aplicaciones y menos en los detalles del sistema para desplegarlo en los diferentes entornos.<\/p>\n\n\n\n
CI \/ CD es una de las mejores pr\u00e1cticas 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\u00f3n de la automatizaci\u00f3n, los programadores pueden desplegar cambios con m\u00e1s frecuencia y los equipos de operaciones ven una mayor estabilidad porque los entornos tienen configuraciones est\u00e1ndar, hay pruebas continuas en el proceso de entrega, las variables de entorno est\u00e1n separadas de la aplicaci\u00f3n y los procedimientos de reversi\u00f3n est\u00e1n automatizados.<\/p>\n\n\n\n
El impacto de la implementaci\u00f3n de pipelines de CI \/ CD se puede medir como un indicador clave de rendimiento (KPI) de DevOps. Los KPI, como la frecuencia de implementaci\u00f3n, el tiempo de espera del cambio y el tiempo medio de recuperaci\u00f3n (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.<\/p>\n\n\n\n
Comenzar con CI \/ CD implica que los equipos de desarrollo y los equipos de operaci\u00f3n colaboren en tecnolog\u00edas, pr\u00e1cticas y prioridades. Los equipos deben desarrollar un consenso sobre los enfoques correctos para sus negocios y tecnolog\u00edas, de modo que una vez que est\u00e9 implementado CI \/ CD , el equipo lo aplique de manera consistente.<\/p>\n\n\n\n