Llegamos a ustedes gracias a:



Reportajes y análisis

Cómo elegir una plataforma CI/CD basada en la nube

[02/07/2021] Si sus objetivos son el desarrollo de software de alta velocidad y la entrega frecuente de compilaciones de trabajo a producción, debe automatizar al menos parte del proceso de prueba y entrega. Idealmente, eso significa implementar pipelines de CI/CD para sus proyectos, junto con conjuntos de pruebas para detectar errores antes de que los clientes vean el software y los scripts que implementan los pasos de los pipelines.

La integración continua (CI, por sus siglas en inglés) es una metodología para automatizar las compilaciones, el empaquetado y las pruebas de software de manera coherente. La CI ayuda a darle a un equipo cierta confianza en que los cambios, que verifican en el control de versiones del código fuente, no romperán la compilación ni introducirán errores en el software. El punto final de la CI suele ser un registro completo en la rama principal de un repositorio de software.

[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]

La entrega continua (CD, por sus siglas en inglés) automatiza la entrega de software probado a ambientes de infraestructura. Por lo general, eso no significa lanzarlo directamente a producción para ver si los clientes se quejan. Por lo general, las organizaciones comienzan enviando la compilación a un ambiente de desarrollo. Después de que los propios desarrolladores superan la nueva compilación y la lanzan, generalmente pasa a un ambiente de prueba, donde es utilizada por un grupo más amplio de usuarios (a veces solo probadores internos y dedicados, otras veces un grupo más grande de usuarios inscritos para pruebas beta o "dog-fooding) y monitoreados de cerca. Finalmente, si todo va bien, los evaluadores firman y envían la nueva versión a un ambiente de producción.

En cada etapa de la CD, hay opciones para volver rápidamente a una compilación anterior y generar tickets de informes de errores con el fin de que los desarrolladores las aborden en la nueva compilación. El objetivo no es enviar muchas compilaciones a producción, sino mejorar continuamente y mejorar el software sin introducir regresiones. Otro término para estas prácticas es "DevOps.

¿Por qué alojar la CI/CD en la nube?

Alojar una plataforma de CI/CD en su propio centro de datos es una opción viable, especialmente para las empresas que exigen alojar sus aplicaciones y datos dentro del firewall. La desventaja de hacer esto es que necesitará un equipo dedicado para mantener la infraestructura e incurrirá en algunos gastos de capital para los servidores.

Si se le permite alojar en la nube, suele ser una mejor opción. El costo del alojamiento en la nube es modesto y ese gasto operativo se compensa con los servicios prestados: incorporación, mantenimiento de la infraestructura, mantenimiento de la seguridad, soporte y mantenimiento del software de CI/CD. Con frecuencia, alojar su software CI/CD en la nube facilita y agiliza la interacción de los pipelines con sus repositorios de código fuente, si estos también están en la nube. Si sus desarrolladores y evaluadores están distribuidos geográficamente, alojar sus repositorios en la nube ofrece a los desarrolladores una mejor experiencia que el alojamiento en servidores remotos detrás de firewalls.

También es posible implementar la CI/CD en un híbrido de servidores on premises y en la nube. Varias de los últimos productos de CI/CD se ejecutan en contenedores en clústeres de Kubernetes, que son igualmente adecuados para ejecutarse en on premises y en la nube. En un escenario de implementación híbrida, puede colocar cada componente donde tenga más sentido, dada la ubicación física de los propios desarrolladores y las ubicaciones de red de los otros servidores en la infraestructura de desarrollo.

La CI/CD debe integrarse con sus repositorios

Como puede haber deducido cuando leyó "el punto final de la CI es generalmente un registro completo en la rama principal de un repositorio de software, los repositorios son esenciales para la CI y la CD. Más allá de ser el punto final del proceso de registro y prueba, los repositorios de software son el lugar preferido para almacenar sus scripts de CI y CD y los archivos de configuración. Sí, muchas de las plataformas de CI/CD pueden almacenar scripts y otros archivos internamente. Sin embargo, por lo general, es mejor tenerlos en el control de versiones fuera de la herramienta.

Casi todas las herramientas de CI/CD pueden interactuar con Git. Algunas también se integran directamente con GitHub, GitHub Enterprise, GitLab y/o Bitbucket. Algunos también son compatibles con Subversion y/o Mercurial.

Sus herramientas de CI/CD deben soportar sus herramientas y lenguajes de programación

Cada lenguaje de programación o grupo de lenguajes (lenguajes JVM, lenguajes compilados LLVM, lenguajes .NET, etc.) tiende a tener sus propias herramientas de construcción y de prueba. Para que le resulte útil, una herramienta de CI/CD debe soportar todos los lenguajes que forman parte de un proyecto determinado. De lo contrario, es posible que deba escribir uno o más complementos para la herramienta.

Las imágenes de Docker son cada vez más importantes para las implementaciones de software distribuido, modular y de microservicios. Es de gran ayuda si su herramienta de CI/CD sabe cómo manejar las imágenes de Docker, incluida la creación de una imagen a partir de su código fuente, binarios y requerimientos previos, así como la implementación de una imagen en un ambiente específico. Nuevamente, a falta de esto, es posible que deba escribir complementos o scripts para implementar la funcionalidad de Docker que necesita. De manera similar, su herramienta de CI/CD debe ser compatible con Kubernetes y cualquier otro sistema de orquestación de contenedores que utilice en sus ambientes.

¿Sus desarrolladores comprenden la CI/CD y las herramientas que está considerando?

Los principios de la CI y de la CD pueden parecer obvios, pero los detalles no lo son. Las diversas herramientas de CI/CD tienen diferentes niveles de soporte y documentación. Hay varios libros sobre Jenkins, lo cual no es sorprendente, ya que es el más antiguo del grupo. Para otros productos, es posible que deba investigar la documentación y los foros de soporte, así como las opciones de soporte de pago como parte de su responsabilidad al elegir una herramienta.

Para obtener información general sobre la CI, considere el libro Continuous Integration de Addison-Wesley de Duvall et al. Del mismo modo, para obtener información general sobre la CD, considere Continuous Delivery de Humble y Farley. Ambos libros ganaron premios Jolt cuando se publicaron.

Puede elegir diferentes herramientas de CI/CD para diferentes proyectos

Si bien esta guía trata sobre la elección de una plataforma de CI/CD, no asuma que una plataforma será óptima para todos sus proyectos de desarrollo de software. La mayoría de los usuarios utilizan varios lenguajes y ambientes de programación, y no todas las plataformas de CI/CD son compatibles con todos ellos.

Siéntase libre de elegir las plataformas de CI/CD que funcionen mejor para cada uno de sus proyectos en lugar de encontrar una única plataforma de compromiso. Los principios generales de la CI y de la CD se transfieren de una plataforma a otra, aunque los scripts que escriba para ellos no siempre sean portátiles. Si bien el tiempo de incorporación adicional para cada nueva plataforma puede costarle algo de tiempo a su equipo de devops, lo más probable es que sea menos costoso que la necesidad de personalizar ampliamente una herramienta de CI/CD.

Planificar la futura migración de CI/CD

En la misma línea, no asuma que una determinada plataforma de CI/CD podrá satisfacer las necesidades de sus proyectos para siempre. Siempre cubra sus alternativas, por ejemplo, almacenando scripts en repositorios en lugar de dentro de la herramienta de CI/CD.

Prefiera una CI/CD sin servidor cuando corresponda

En general, las implementaciones de contenedores en la nube son menos costosas que las implementaciones de instancias de servidores en la nube, y las implementaciones en la nube sin servidor son menos costosas que las implementaciones de contenedores. Desafortunadamente, pocas plataformas de CI/CD pueden funcionar sin servidor en el momento de escribir este artículo.

Sin servidor significa que el contenedor que ejecuta el proceso de interés crea una instancia según sea necesario, generalmente en respuesta a un evento. Para la CI/CD, el evento desencadenante es, generalmente, un registro de código en una rama de repositorio específica; el Webhook del repositorio lanza el proceso sin servidor. Cuando se completa el proceso, se liberan los recursos.

Una de las pocas plataformas de CI/CD que pueden funcionar sin servidor es Serverless CI/CD, que parte de Serverless Framework Pro, una versión mejorada del marco sin servidor de código abierto. Serverless CI/CD está optimizada para implementar aplicaciones sin servidor y actualmente solo se ejecuta en AWS. Tendrá que determinar si es compatible con su aplicación lo suficientemente bien como para usarla.

¿Dónde están sus activos actuales en la nube?

Para optimizar una configuración de CI/CD basada en la nube (o cualquier aplicación en la nube), es útil que todos sus activos estén "cerca unos de otros. "Cerca en este contexto se refiere parcialmente a la ubicación geográfica y parcialmente a la ubicación de la red.

Por ejemplo, si su base de datos está en Australia y su aplicación está en América del Norte, tendrá un gran retraso cada vez que la aplicación necesite leer o escribir datos. A menor escala, si su aplicación y base de datos están en la misma zona de disponibilidad (AZ, por sus siglas en inglés), la latencia entre ellas se minimizará. Si están en diferentes zonas de la misma región, la latencia será mayor, pero no tan alta como si estuvieran en diferentes regiones.

Del mismo modo, si su base de datos está en Google Cloud Platform en Virginia y su aplicación está en Microsoft Azure en Virginia, la latencia será mayor que si ambos estuvieran en el mismo proveedor de nube en la misma zona de disponibilidad. Todo esto también se aplica a su repositorio (que es esencialmente una base de datos), su software de CI/CD, su aplicación real y sus desarrolladores y evaluadores. Ayuda si todos están "cerca, aunque los efectos del retraso no son tan evidentes en esta situación como lo serían para, digamos, un juego interactivo en tiempo real.

Si los desarrolladores pueden enviar confirmaciones de código al repositorio principal de manera confiable y sin tiempos de espera notables, generalmente estarán contentos. Del mismo modo, si los usuarios y evaluadores están lo suficientemente "cerca de la aplicación para obtener tiempos de respuesta inferiores a un segundo, también estarán felices. Para el software CI/CD, la clave son las conexiones confiables a los puntos de implementación. Un pequeño retraso puede ser tolerable siempre que no provoque tiempos de espera o paquetes descartados.

Haga una prueba de concepto antes de comprometerse

Una vez que las haya implementado por completo, la CI/CD será una parte fundamental de su infraestructura. Téngalo en cuenta a medida que se pone al día.

Es importante realizar una rigurosa prueba de concepto antes de comenzar a implementar los pipelines de CI/CD. Adapte la porción de CI antes de comenzar la fase de CD. Asegúrese de ejercitar sus conjuntos de pruebas y capacidades de reversión antes de conectar cualquier pipeline de CI/CD a instancias de producción, y mantenga a los humanos informados hasta que esté seguro de que la automatización es sólida como una roca.

Crédito foto: tine ivanic / CC0