Comprender los procesos de CI/CD
Si ha leído acerca de la integración continua, la entrega y la implementación (conocido colectivamente como la CI/CD), muy probablemente se habrá encontrado con el término «proceso automatizado» y sabrá que desempeña un papel fundamental en la implementación de estas prácticas. ¿Pero qué es exactamente un proceso de integración continua/entrega continua? ¿Y cómo puede obtener uno?
El objetivo de la CI/CD es reducir el tiempo que se tarda en entregar el software a los usuarios sin sacrificar la calidad. Para conseguirlo, tiene que comprobar los cambios con frecuencia, probarlos de manera rigurosa y gestionar los comentarios con rapidez, de manera que pueda implementar sus cambios en la versión pública con la frecuencia que desee.
¿Qué es un proceso de CI/CD?
Cuando hablamos de un proceso de CI/CD, nos referimos a la serie de pasos por los que transcurre su código para salir de su máquina de desarrollo, por las fases de prueba y preparación, hasta llegar a las manos de sus usuarios.
Como la estrategia de CI/CD es ejecutar este proceso de forma muy regular (generalmente varias veces al día), resulta clave automatizar lo máximo posible, y que cada paso active el siguiente o dé un aviso si algo ha salido mal.
La automatización no solo acelera el proceso general y, por lo tanto, los bucles de feedback individuales, sino que también garantiza que cada paso se realice de manera coherente y fiable.
Etapas de un proceso de compilación
Aunque la forma exacta de su proceso de CI/CD dependerá del tipo de producto que esté creando, además de los requisitos de su organización, existe un patrón general que todos los procesos suelen seguir, que describimos aquí.
El proceso comienza con una confirmación en el máster (o en cualquier rama que haya designado como la rama de la CI), que desencadena un build o un conjunto inicial de pruebas de unidad. Los resultados se envían de vuelta a un panel y, si falla el build o la prueba, se marca con una notificación automática.
Puede configurar el proceso para que se detenga a fin de que pueda abordar el problema y comenzar de nuevo con una nueva confirmación, o crear excepciones para tipos concretos de errores para que el proceso pueda continuar.
La siguiente etapa implica una serie de pruebas automatizadas, con feedback proporcionado después de cada ronda de pruebas. Por lo general, las pruebas están estructuradas para que las pruebas más rápidas se ejecuten primero y ofrezcan feedback lo antes posible.
Las pruebas más elaboradas que ocuparán los servidores durante más tiempo, como las pruebas de extremo a extremo, solo se ejecutan cuando las pruebas anteriores se han completado correctamente. Esto permite un uso más eficiente de los recursos.
Una vez que se han completado las pruebas automatizadas, el software se suele implementar en una serie de entornos de pruebas, algunos de los cuales se pueden usar para pruebas manuales adicionales, mientras que otros se pueden usar para formación, asistencia y vistas previas del cliente.
La etapa final de la arquitectura del proceso de CI/CD consiste en implementar los cambios y puede activarse manualmente (en el caso de la entrega continua) o automáticamente (como en el caso de la implementación continua).
Veamos algunas consideraciones para cada una de estas etapas con un poco más de detalle.
Indicadores y ramas
El primer paso hacia la adopción de la integración continua es colocar toda su base de código en un sistema de control de versiones (VCS, también conocido como gestión de control de fuentes o SCM), como Git, Mercurial o Perforce, y después hacer que todos los miembros de su equipo adquieran el hábito de confirmar sus cambios con frecuencia. Cada confirmación en el máster inicia el proceso, compilando y probando el código para proporcionar un feedback rápido sobre lo que ha escrito.
Aunque las confirmaciones frecuentes son una práctica importante del proceso de CI/CD, si está trabajando en una funcionalidad más grande que tardará varios días o semanas en completarse, realizar confirmaciones periódicas durante ese proceso puede ser un arma de doble filo.
Al hacer push de sus cambios a través del proceso en incrementos regulares le proporciona un feedback rápido y reduce la probabilidad de que haya conflictos más complejos que si espera hasta el final.
Por otro lado, probablemente no quiera ofrecer a los usuarios una funcionalidad a medio terminar, y tal vez tampoco esté listo para compartir su trabajo en progreso con usuarios internos a través de entornos de prueba.
Los indicadores de funcionalidades y las ramas de funcionalidades ofrecen formas de solucionar este problema. Con los indicadores de funcionalidades, puede especificar los entornos en los que su código será visible para los usuarios. Sus cambios se siguen confirmando en el máster y son visibles para su equipo, pero usted decide cuándo estará disponible la funcionalidad en la etapa de preparación y de producción.
Las ramas de funcionalidades le permiten desarrollar su funcionalidad en una rama separada sin perder las ventajas de la compilación y pruebas automatizadas. Al desencadenar el proceso de CI/CD en cada confirmación con una rama de funcionalidad, al igual que lo hace con una confirmación en el máster, puede obtener feedback rápido sobre lo que ha creado.
Compilación y prueba
Después de haber desencadenado una instancia de su proceso con una confirmación, las siguientes etapas son la compilación y la prueba. Si tiene pruebas de unidades automatizadas, estas se ejecutan normalmente antes del build con comprobaciones de análisis estático y de análisis lint.
La herramienta de build que utilice (como Ant o Maven) y los detalles de los pasos de compilación dependerán del lenguaje y del marco de trabajo en los que trabaje. Al ejecutar el build automatizado en un servidor de builds dedicado, puede evitar problemas en el futuro causados por dependencias que falten; el clásico problema de «funciona en mi máquina».
El resultado del paso de build incluye los instaladores, binarios o contenedores (los artefactos del build), que después se implementan en entornos de prueba y se combinan con otras partes del sistema para ejecutar pruebas automatizadas de nivel superior: pruebas de integración, pruebas de componentes y pruebas de extremo a extremo, así como pruebas no funcionales, como análisis de rendimiento y seguridad.
Estas pruebas se pueden ejecutar en paralelo para acelerar el proceso y ofrecerle antes el feedback.
Contenedores vs. máquinas virtuales
Para que los resultados de sus pruebas automatizadas sean fiables, tiene que asegurarse de que se ejecuten de forma coherente.
Lo ideal es que sus entornos de pruebas se configuren para parecerse lo más posible a la producción, y deben restablecerse entre las ejecuciones de las pruebas para evitar incoherencias ambientales que interrumpan los resultados de las pruebas.
Durante mucho tiempo, las máquinas virtuales (VM) han sido una opción popular para ejecutar entornos de pruebas, ya que puede programar el proceso de actualización para cada nuevo build que se prueba.
Sin embargo, deshacer y reactivar nuevas máquinas virtuales lleva tiempo, mientras que sus scripts deberán incluir la configuración de cada entorno virtual para proporcionar todas las dependencias que necesita el software para ejecutarse. Cuando se añaden nuevas dependencias, los scripts de entorno tendrán que actualizarse. Si pasa por alto este detalle, el build no se ejecutará.
Puede evitar estos problemas empaquetando su código en un contenedor como parte del paso inicial del build. Un contenedor incluye todas las dependencias que necesita el software para ejecutarse, lo que lo hace altamente portátil y más fácil de implementar en diferentes entornos.
Aunque aloje su CI/CD en su propia infraestructura, seguirá necesitando máquinas virtuales para implementar los contenedores, aunque la preparación del entorno de pruebas requerirá menos trabajo, lo que ayuda a que el proceso funcione de manera eficaz. Si ejecuta su proceso en la nube, puede usar servicios gestionados para adoptar contenedores y descargar el lado de la infraestructura a su proveedor de nube.
Entornos de preproducción
La cantidad de entornos de prueba y preparación en su arquitectura de proceso dependerá de lo que esté creando y de las necesidades de los distintos grupos de partes interesadas en su organización. Por ejemplo, puede tratarse de pruebas exploratorias, revisiones de seguridad, investigaciones sobre los usuarios, demostraciones de ventas, entornos de formación y entornos de pruebas para que el personal de asistencia pueda replicar los problemas de los clientes.
Automatizar la creación y la implementación en estos entornos es más eficaz que actualizarlos manualmente, y puede configurar distintos desencadenadores del proceso para diferentes entornos.
Por ejemplo, aunque sus entornos de pruebas pueden actualizarse con cada build, tal vez quiera actualizar los entornos de pruebas con menos frecuencia; tal vez una vez al día o una vez a la semana con el último build exitoso.
Despliegue
Una vez que los cambios del código hayan superado todas las etapas anteriores del proceso, estarán listos para lanzarse a producción. Ese paso final puede ser manual o automático.
El lanzamiento manual (conocido como entrega continua) es útil si desea controlar cuándo se vuelven disponibles las nuevas funcionalidades, si su proceso de implementación implica un tiempo de inactividad para sus usuarios o si su producto está instalado y desea agrupar los cambios y entregarlos de acuerdo con un calendario periódico de lanzamientos.
Con un proceso de implementación continua totalmente automatizado, los cambios se implementan para que estén activos siempre que hayan pasado todas las etapas anteriores.
En función de la cantidad de desarrolladores que trabajen en la base de código y de la frecuencia de sus confirmaciones, esto puede significar que está implementando actualizaciones para los usuarios docenas de veces al día; una hazaña prácticamente imposible sin un proceso automatizado.
Entender los procesos de CI/CD: resumen
La CI/CD hace que el desarrollo de software sea más eficaz al resaltar los problemas lo antes posible; le ayuda a fallar rápidamente moviendo las interacciones antes y recibiendo el feedback antes (también conocido como desplazamiento hacia la izquierda). La creación de un proceso automatizado le ayuda a poner en práctica estas técnicas.
Cuando se trata de diseñar su propio proceso de CI/CD, es útil construirlo en etapas, comenzando con la integración continua. Las etapas exactas del proceso y la lógica que determina cuándo se desencadena cada etapa dependen de su producto y su organización.
Elegir una plataforma de CI/CD que le brinde la flexibilidad necesaria para configurar su proceso según sus necesidades, sin dejar de ser fácil de gestionar, le ayudará a forjar un proceso de publicación fiable y mejorar la calidad de su software.