Automatización de pruebas y canalización de entrega

Has aprendido sobre la implementación continua y la entrega de software y servicios, pero estos dos forman parte realmente de una tríada. Las prácticas de DevOps están destinadas a lograr la integración, la entrega y la implementación continuas. Normalmente, estas prácticas se crean en ese orden, con cada una en función de la anterior.

Ahora, es el momento de realizar una copia de seguridad y analizar la primera de estas: integración. Forma parte del proceso de desarrollo que tiene lugar antes de la implementación. DevOps recomienda como práctica de desarrollo que los miembros del equipo integren con frecuencia código en un repositorio compartido que contenga una base de código única de tipo "principal" o "troncal". El objetivo consiste en que todas las personas contribuyan al código que se va a enviar, en lugar de trabajar en su copia y no juntarlo todo hasta el último minuto.

Después, las pruebas automatizadas pueden comprobar la integración de cada miembro del equipo. Estas pruebas ayudan a determinar que el código está "en buen estado" después de cada cambio y adición realizada. Las pruebas forman parte de lo que normalmente se denomina tubería. El resto de esta unidad se centra en las canalizaciones de entrega y pruebas integradas.

Canalización de entrega continua

Para comprender el rol de las pruebas automatizadas en el modelo de implementación de entrega continua, debe examinar dónde encaja en la canalización de entrega. Una canalización de entrega continua es la implementación del conjunto de pasos que recorre el código cuando se realizan cambios durante el proceso de desarrollo, antes de su implementación en producción. Esta es una representación gráfica de los pasos de ejemplo en una canalización de entrega simplificada:

Siga este proceso paso a paso:

• Una instancia de la canalización se inicia cuando se confirman los cambios de código o de infraestructura en un repositorio de código, quizás mediante una solicitud de incorporación de cambios.

• A continuación, las pruebas unitarias se ejecutan, a menudo seguidas de las pruebas de integración o de un extremo a otro. Los resultados se comunican de nuevo al desarrollador que abrió la solicitud de incorporación de cambios.

• En esta fase, el código del repositorio suele examinarse en busca de secretos, vulnerabilidades y configuraciones incorrectas.

• Cuando todo se haya comprobado, el código se compilará y se preparará para la implementación.

• Después, el código se implementará en un entorno de prueba. Un revisor puede recibir una notificación de la nueva implementación para que pueda examinar la solución de preproducción. A continuación, el revisor aprueba o deniega la promoción a producción, que inicia la parte final del proceso de implementación que libera el código en producción.

En este proceso, puede ver la delimitación entre la integración y la implementación. Los marcadores resaltados señalan algunos lugares lógicos en los que puede detener la canalización a través de la lógica y la automatización incluidas, o incluso la intervención humana.

Herramientas para la integración y entrega continuas: Azure Pipelines y GitHub Actions

Para usar la integración y la entrega continuas, necesita las herramientas adecuadas. Microsoft ofrece dos opciones de CI/CD de primera entidad para compilar e implementar en Azure: Azure Pipelines (parte de Azure DevOps) y GitHub Actions. Ambos pueden automatizar la compilación y probar de forma coherente el código, y ambos pueden implementarse en Azure servicios, máquinas virtuales y otros destinos en la nube y en el entorno local. Muchos equipos adoptan GitHub Actions cuando su código fuente ya reside en GitHub, mientras que Azure Pipelines sigue siendo una opción segura para los equipos estandarizados en Azure DevOps.

El resto de esta unidad se centra en Azure Pipelines, pero GitHub Actions usa ideas de alto nivel similares aunque la terminología sea diferente. En GitHub Actions, los flujos de trabajo contienen trabajos y pasos, las acciones empaquetan la automatización reutilizable, los ejecutores ejecutan el trabajo y los entornos pueden proteger las implementaciones.

Los datos de entrada en una canalización (el código o configuraciones que implemente) residen en un sistema de control de versiones como GitHub u otro proveedor de GIT.

Azure Pipelines se ejecuta en cómputo, como una máquina virtual o un contenedor, y ofrece agentes de compilación hospedados por Microsoft que ejecutan Windows, Linux y macOS. También puede registrar sus propios agentes autohospedados cuando necesite un control total sobre el entorno de compilación. También ofrece integración con complementos de prueba, seguridad y calidad de código. Por último, es fácilmente extensible, por lo que puede traer su propia automatización a Azure Pipelines.

Las canalizaciones se definen mediante la sintaxis YAML almacenada junto con el código en un repositorio de Git. Las canalizaciones YAML son el enfoque recomendado para los nuevos proyectos. Una interfaz de usuario clásica en Azure DevOps también está disponible para canalizaciones heredadas, pero la mayoría de las nuevas funcionalidades (incluidos los trabajos de contenedor y muchas características avanzadas) son solo YAML. Las canalizaciones también proporcionan plantillas que puede usar para crear fácilmente canalizaciones, como una plantilla para una imagen de Docker o un proyecto de Node.js. También puede reutilizar un archivo YAML existente.

Los pasos básicos para configurar una canalización son:

1. Configure Azure Pipelines para usar el repositorio de Git.
2. Defina la compilación editando el archivo azure-pipelines.yml (o, para canalizaciones heredadas, mediante el editor clásico).
3. Inserte el código en el repositorio de control de versiones. Esta acción activa la canalización para compilar y probar tu código.

Una vez que el código se ha actualizado, compilado y probado, puede implementarlo en el destino que quiera.

construcción de canalización de Azure

Las canalizaciones se estructuran en:

• Trabajos: un trabajo es una agrupación de tareas o pasos que se ejecutan en un único agente de compilación. Un trabajo es el componente de trabajo más pequeño que se puede programar para su ejecución. Todos los pasos de un trabajo se ejecutan secuencialmente. Estos pasos pueden ser cualquier acción que necesite, incluyendo la creación o compilación de software, la preparación de datos de ejemplo para pruebas, la ejecución de pruebas específicas, etc.

• Fases: una fase es una agrupación lógica de trabajos relacionados.

Cada canalización tiene al menos una fase. Use varias fases para organizar la canalización en divisiones principales y marque los puntos de la canalización en los que se puede pausar y realizar comprobaciones.

Las canalizaciones pueden ser tan simples o tan complejas como se quiera. Para ver tutoriales sobre la construcción y el uso de canalizaciones, consulte la ruta de aprendizaje Build applications with Azure DevOps learning path (Aplicaciones de Azure DevOps.

Rastreabilidad del entorno

Hay otro aspecto de las canalizaciones que merece la pena mencionar en relación con la confiabilidad. Puede construir las canalizaciones de tal manera que se pueda correlacionar lo que se ejecuta en producción con una instancia de compilación específica. Lo ideal es que pueda hacer un seguimiento de la compilación hasta una solicitud de incorporación de cambios específica o un cambio de código. Esta rastreabilidad es valiosa durante un incidente y, después, durante la revisión posterior al incidente cuando intenta identificar qué cambio ha contribuido a un problema. Algunos sistemas de CI/CD (como Azure Pipelines y GitHub Actions) facilitan esta correlación, mientras que otros requieren que cree manualmente una canalización que propague un identificador de compilación a través de cada fase.