Montar un flujo de trabajo en GitHub Actions que ejecute las pruebas lleva veinte minutos. Montar uno en el que confíes para desplegar a producción un viernes por la tarde es otra cosa. La diferencia no está en la sintaxis del YAML, está en cuatro decisiones que casi nadie toma al principio y que después cuesta mucho corregir.
Las etapas mínimas
Un pipeline serio tiene al menos cinco fases, y el orden no es casual: cada una es más lenta y más cara que la anterior, así que las baratas van primero para fallar cuanto antes.
- Análisis estático y formato. Segundos. Detecta lo tonto antes de gastar minutos de máquina.
- Pruebas unitarias. Rápidas y sin dependencias externas.
- Construcción del artefacto. Una sola vez. El mismo artefacto que pasa las pruebas es el que llega a producción: si reconstruyes por entorno, no estás desplegando lo que probaste.
- Pruebas de integración. Contra dependencias reales levantadas como servicios del propio flujo.
- Despliegue. Progresivo y con vuelta atrás automática.
Deja de guardar claves de acceso
Si tu pipeline tiene guardadas unas credenciales permanentes de tu proveedor cloud, tienes un problema de seguridad esperando a ocurrir. Cualquiera con permiso para modificar un flujo de trabajo puede exfiltrarlas, y en la práctica esas claves no se rotan nunca.
La alternativa es la federación de identidades con OIDC: GitHub emite un token de corta duración por ejecución y tu proveedor lo valida contra una relación de confianza que tú defines. No hay ningún secreto que robar porque no hay ningún secreto. Se configura una vez y elimina de golpe toda una categoría de riesgo.
En la misma línea: declara permisos mínimos explícitos en cada flujo. Por defecto el token de GitHub tiene más permisos de los que tu pipeline necesita.
Un pipeline lento es un pipeline que se salta
Esto no es una cuestión de comodidad. Cuando el pipeline tarda veinticinco minutos, la gente agrupa cambios para no esperar, y los lotes grandes son justo lo que hace que los fallos sean difíciles de diagnosticar. La velocidad del pipeline determina el tamaño de los cambios, y el tamaño de los cambios determina cuánto duele cada incidencia.
Tres palancas, por orden de rentabilidad: cachear dependencias entre ejecuciones, paralelizar todo lo que no dependa entre sí, y construir imágenes por capas para que un cambio de código no reinstale el sistema entero. Con eso es habitual bajar de veinte minutos a menos de cinco.
Entornos, aprobaciones y vuelta atrás
Los entornos de GitHub permiten exigir aprobación manual antes de que un despliegue toque producción y restringir qué ramas pueden llegar hasta ahí. Es la forma correcta de tener una puerta de control sin convertirla en un proceso burocrático fuera del flujo.
Y lo más importante: el despliegue debe saber volver atrás solo. Si tu plan de contingencia es «alguien lanza el flujo de la versión anterior a mano», tu tiempo de recuperación depende de que esa persona esté despierta. Un despliegue progresivo que vigila métricas y revierte al detectar degradación convierte una incidencia de una hora en un sobresalto de dos minutos.
Los errores que más vemos
- Reconstruir el artefacto en cada entorno, con lo que producción ejecuta algo que jamás pasó las pruebas.
- Fijar acciones de terceros por etiqueta móvil en vez de por hash. Si esa etiqueta se reescribe, estás ejecutando código nuevo sin enterarte.
- Pruebas inestables toleradas durante meses. Un pipeline que falla aleatoriamente enseña al equipo a ignorar los fallos, y ese hábito acaba costando una incidencia real.
- Configuración duplicada en quince flujos. Cuando hay que cambiar algo, se cambia en once.
¿Tu pipeline da más problemas de los que resuelve? Cuéntanos cómo desplegáis hoy →
Sigue leyendo
- Cuatro métricas para saber si tu DevOps funciona de verdad
- Seguridad en el pipeline sin frenar al equipo
Puedes ver todo lo que hacemos en servicios, o echar un vistazo a los tipos de proyecto que solemos abordar.