¿Cómo decidirías qué tests se ejecutan en cada etapa del pipeline de CI?

Ordena las etapas por coste y velocidad de feedback. En cada commit, ejecuta linting y tests unitarios, apuntando a unos pocos minutos. En los pull requests, añade tests de integración y de contrato. Tras el despliegue a un entorno compartido, ejecuta pruebas de humo como puerta de promoción. Deja la suite completa de regresión y las comprobaciones lentas, como rendimiento y accesibilidad, para la noche o para antes de la release.

Lo diseño en torno a cuánto va a esperar de verdad un desarrollador, que no es mucho. En cada commit: linting, análisis estático y tests unitarios, y eso lo mantengo por debajo de unos cinco minutos, porque a partir de ahí la gente cambia de contexto y el feedback pierde casi todo su valor. En un pull request: tests de integración contra dependencias reales en contenedores, más tests de contrato, para que cualquier cosa que rompa otro servicio falle aquí y no en un entorno compartido. Tras el despliegue, una suite de humo que condiciona la promoción, quizá quince tests que demuestren que el build está vivo y que los recorridos críticos funcionan. Luego, de noche, la ejecución completa de regresión más las comprobaciones caras, o sea rendimiento, escaneos de accesibilidad, y análisis de dependencias y de seguridad. Antes de una release, una pasada dirigida basada en riesgo sobre lo que cambió. La regla que hago cumplir es que si una etapa es una puerta, entonces bloquea de verdad, y si no bloquea no debería presentarse como puerta, porque un pipeline permanentemente en rojo por el que todo el mundo mergea es peor que no tener pipeline. Que es también por lo que los tests inestables salen de las etapas que bloquean de inmediato y se quedan en cuarentena hasta que se arreglan.