¿Crees que es correcto combinar la compilación, las pruebas y la publicación de la imagen en un flujo de trabajo, así como agregar pasos para el despliegue en diferentes entornos?

Esto no siempre es óptimo. Aunque este enfoque puede ser conveniente para proyectos pequeños o compilaciones de prueba locales, combinar todas las etapas en un solo flujo de trabajo tiene desventajas:

• Reducción de la flexibilidad: El despliegue en diferentes entornos (dev, staging, producción) requiere diferentes parámetros y a menudo diferentes permisos de acceso. La unión complica la gestión de estas diferencias.
• Dependencia del entorno: Si el despliegue en uno de los entornos falla, toda la compilación se considera fallida, incluso si la creación de la imagen y su prueba fueron exitosas.
• Dificultad para revertir: La reversión del despliegue se vuelve menos trivial, ya que hay que revertir todo el flujo de trabajo.
• Aumento del tiempo de ejecución: Todo el pipeline lleva más tiempo, lo que ralentiza la retroalimentación para los desarrolladores.
• Menor escalabilidad: A medida que crece el proyecto y aumenta el número de entornos de despliegue, dicho flujo de trabajo se vuelve engorroso y difícil de gestionar.

Una práctica más común y flexible es dividir estas etapas:

1. Pipeline de construcción y prueba: Se encarga de compilar el código, realizar pruebas, construir la imagen y almacenarla en un registro de artefactos (por ejemplo, Docker Registry, Nexus). Este flujo de trabajo se ejecuta por cada commit o pull request.
2. Pipeline de despliegue: Flujos de trabajo separados para desplegar en cada entorno. Toman la imagen ya construida y probada del registro de artefactos y la despliegan en el entorno objetivo. Estos flujos pueden iniciarse manualmente, por programación o automáticamente tras la finalización exitosa de la etapa anterior (por ejemplo, despliegue exitoso en staging).

Esto permite:

• Obtener retroalimentación más rápida sobre la calidad del código (build & test).
• Desplegar en diferentes entornos de forma independiente.
• Gestionar de manera más flexible los parámetros de despliegue para cada entorno.
• Simplificar el proceso de reversión.

Una excepción puede ser pequeños proyectos pet o aplicaciones monolíticas con un proceso de despliegue simple, donde los costos adicionales de dividir superan los beneficios. Sin embargo, en la mayoría de los entornos corporativos, dividir el flujo de trabajo es una mejor práctica.