La próxima ola de CI/CD - Diseño y automatización de procesos visuales de CI/CD

La integración continua (IC) y la entrega continua (CD) son un conjunto de mejores prácticas diseñadas para permitir que los equipos de desarrollo creen, modifiquen, mejoren y entreguen los cambios de productos con mayor frecuencia y con menos errores. Todo el proceso se denomina normalmente CI/CD tubería.

Pruebas como parte de la Integración Continua (CI) y la Entrega Continua (CD)

Una de las partes más importantes de la IC/CD es la prueba. Las pruebas también deben ser continuas por definición. Recuerden, nuestra preocupación es asegurarnos de entregar aplicaciones de calidad a nuestros interesados. Las pruebas continuas consistirán en la ejecución de regresiones automatizadas, pruebas funcionales, pruebas de unidad y pruebas de rendimiento. Estas pruebas deben ser ejecutadas como parte de la tubería de CI/CD.

Herramientas de CI/CD como Jenkins, CircleCI, AWS CodeBuild, Travis CI, Bambú del Atlas...u otras son las herramientas de elección hoy en día para la IC/CD. Todas permiten a los ingenieros de DevOps incorporar pruebas automatizadas. Además, servicios como SauceLabs permiten que la IC/CD se ejecute a gran escala y con SLAs de nivel empresarial. Y hay un montón de otras herramientas innovadoras que deberían estar en su carcaj de pruebas - herramientas como scriptworks.io por usar un enfoque de código bajo para crear sus guiones de Selenio.

Sin embargo, hoy quiero hablar sobre cómo llevar la automatización de CI/CD al siguiente nivel introduciendo el diseño de procesos visuales en su conjunto de herramientas de CI/CD. ADVERTENCIA - Como cualquier tecnología, esto no es para todos y no para cada situación. Para muchos de ustedes, esto será una exageración y pueden rascarse la cabeza pensando "por qué necesito esto". Puede que no lo necesites.

¿Qué tipo de proyectos deben utilizar el Visual CI/CD?

Entonces, ¿quién debería estar interesado en añadir la automatización del proceso visual de CI/CD a su actual proceso de CI/CD? Aquí están algunas de las características a tener en cuenta para ver si su proyecto de software debería utilizar la automatización del proceso visual como una integración/extensión de su herramienta de CI/CD:   

• Multi-tenancy - Está ejecutando una aplicación SaaS multi-inquilino
• Participación de los interesados - Tiene clientes o socios que necesitan participar en el proceso de diseño y supervisión de la calidad y la entrega del código
• Personalización - Su aplicación permite a los clientes personalizar la aplicación, y como resultado sus pruebas de selenio funcional tenderán a crecer y cambiar con frecuencia (en mi humilde opinión, esta puede ser la mayor razón para usar el diseño del proceso visual de CI/CD).
• Pasos de aprobación manual - Es posible que necesite pasos de aprobación manual para ciertos tipos de actualizaciones de los inquilinos, el cumplimiento de la ISO y de la normativa, o debido a las estipulaciones en los contratos de los clientes
• Alertas automatizadas y reglas de retroceso - Las partes interesadas y los clientes pueden requerir alertas oportunas debido a los protocolos de seguridad que siguen o que sus clientes les exigen que sigan
• Colaboración - Cada vez más a menudo la IC/CD se está convirtiendo en una función crítica de la empresa y no sólo en una iniciativa dirigida por los desarrolladores. Por ello, los interesados no técnicos querrán entender el proceso y tendrán que colaborar.
• Cadenas de suministro complejas - Para el software que se está construyendo entre equipos y compañías independientes, se necesitará más auditoría visual.
• Ejecución de pruebas paralelas - Los proyectos más grandes necesitan hacer pruebas de Selenio en paralelo para poder hacer las pruebas más rápida y eficientemente.

El selenio simplificado

Hoy, vamos a caminar a través de un ejemplo en vivo de cómo integrar la automatización de procesos visuales para su CI / CD. Hemos construido un proceso robusto y totalmente automatizado utilizando ProcessMaker, una tecnología de automatización de procesos de próxima generación. Creemos que usted verá que esto nos da un enorme nivel de flexibilidad añadida, visibilidad y eficiencia a la forma típica en que QA y CloudOps interactúan para realizar pruebas automatizadas y ejecutar tuberías CI / CD. Como se ha indicado anteriormente, esta solución está dirigida a equipos de ingeniería que necesitan abordar escenarios de pruebas y despliegue de versiones más complejos.

En este ejemplo nuestro proceso se integra con varios servicios relacionados con AWS CI/CD (CodePipeline, CodeCommit, CodeDeploy, y funciones Lambda personalizadas), Github, y Selenio. En su caso, puede elegir utilizar diferentes herramientas de CI/CD como las mencionadas anteriormente. Puede ver el video de la prueba de control de calidad automatizada de ProcessMaker aquí.

Lo que vamos a ver en el video

En nuestra aplicación de muestra, hemos construido una tubería visual de CI/CD para probar una aplicación empresarial multi-inquilino. Esta muestra fue construida para una gran empresa de ERP que necesitaba colaborar con numerosos proveedores. Además, la aplicación podía ser personalizada por los clientes, lo que significaba que para cada actualización, no sólo era necesario probar la aplicación base, sino que los clientes también tendrían que ser capaces de almacenar las pruebas de selenio en sus propios repositorios Git para probarlas antes de desplegar las actualizaciones del software base. Además, algunos clientes podrían estar en nubes públicas con disposiciones de plazos fijos, mientras que otros podrían estar en nubes privadas que requieren un consentimiento manual del cliente después de que se les haya dado un tiempo determinado para revisar cualquier anomalía de sus casos de prueba locales.  

Así que, como puedes ver, en este caso hay varias razones por las que un proceso visual puede mejorar enormemente el uso tradicional de una suite de IC/CD.

Cómo funciona el proceso

Este proceso se inicia a partir de un código de confirmación que ocurre en AWS CodeCommit. Esto desencadena AWS CodePipeline para hacer una llamada a la API de ProcessMaker para iniciar el proceso. ProcessMaker entonces inspecciona la información de CodeCommit para saber qué pruebas funcionales de Selenio deben ser ejecutadas y llama al repositorio o repositorios Github apropiados para cargar la versión correcta de las suites de pruebas a ejecutar.

Las suites de pruebas de Selenium se ejecutan en paralelo, todo gestionado por el motor de flujo de trabajoProcessMaker. La belleza aquí es que ProcessMaker puede manejar la paralelización verdaderamente masiva de pruebas en la nube. Esto puede ser para ejecutar tanto la orquestación y la ejecución, o tal vez sólo la orquestación (cuando se integra con algo como la ejecución de Sauce Labs API fo y presentación de informes adicionales).

Usar las reglas de negocio para evaluar los resultados de las pruebas antes de pasar a CodeDeploy

Las respuestas de la prueba se pasan a ProcessMaker y se almacenan en el objeto ProcessMaker apropiado. Este objeto es evaluado por las reglas de negocio de ProcessMaker para ver si alguna de las pruebas falló. Si alguna de las pruebas falló, alertará a las personas adecuadas y esperará a ser ejecutada de nuevo. Si todo pasa, entonces ProcessMaker hará una llamada a AWS para desplegar el código en producción.

Este proceso es un proceso totalmente automatizado que no requiere ninguna interacción humana. Sin embargo, como el proceso está diseñado visualmente y no está codificado en forma rígida, el proceso puede cambiarse fácil y visualmente. De esta manera, todas las partes interesadas pueden ver y auditar el proceso. Así pues, como mencionamos anteriormente, si un cliente particular requiere un paso de aprobación humana (o varios pasos) antes de pasar a la fase de despliegue del código, podemos ejecutarlo fácilmente sobre la base de una simple regla comercial. Es posible que otros necesiten sacar de varios depósitos github (u otros) que son tanto públicos como privados y son mantenidos por diferentes partes.

Ejecutando pruebas en una imagen personalizada de un Docker

Las pruebas que se extraen de GitHub, en este ejemplo, están escritas en Python usando tareas de guión y una imagen Docker personalizada en ProcessMaker para ejecutar pruebas de Selenio contra ese entorno de destino. ProcessMaker permite a los equipos de control de calidad desarrollar guiones en cualquier lenguaje de programación para llamar a las pruebas de selenio y ejecutarlas en contenedores Docker independientes. Estos contenedores Docker pueden incluso cargar el lenguaje más cualquier librería o SDK adicional según sea necesario.

Por qué incluso los desarrolladores aman el código bajo

Aunque la IC/CD fue inventada por desarrolladores para desarrolladores, su importancia se está moviendo rápidamente más allá del backoffice. Como tal, cada vez más partes interesadas necesitan comprender lo que está sucediendo. Los aspectos legales y de cumplimiento están entrando en escena, lo que significa que la responsabilidad, la indemnización, la certificación y mucho más están afectando ahora a la responsabilidad con la que se ejecuta la IC/CD. Como tal, es una evolución natural de la CI/CD que ahora se requiere algún nivel de herramientas visuales de bajo código o sin código. La verdad es que mientras el flujo de trabajo orquestado visualmente sin código permita a los desarrolladores utilizar sus herramientas favoritas (Docker, Kubernetes, Selenium, Git, etc.) entonces hemos visto que los desarrolladores aman las herramientas extra.

Si desea obtener más información sobre la ejecución de CI/CD visual para ampliar su proceso actual, por favor, póngase en contacto con nosotros en ProcessMaker o eche un vistazo a este vídeo.