DevOps no es una herramienta ni un puesto de trabajo: es una cultura de ingeniería que derriba el muro histórico entre quienes desarrollan el software (Dev) y quienes lo operan en producción (Ops). En el centro de esa cultura está el pipeline de CI/CD, una cadena automatizada que toma cada cambio de código y lo lleva, con verificación continua, hasta los usuarios. Este artículo explica con detalle técnico qué significan la integración continua, la entrega continua y el despliegue continuo, cómo se construye un pipeline real en GitHub Actions y GitLab CI, y qué métricas demuestran que el sistema funciona.
Integración continua, entrega continua y despliegue continuo: tres conceptos distintos
Las siglas CI/CD esconden tres prácticas que conviene separar. La integración continua (CI) consiste en que cada desarrollador fusione sus cambios con la rama principal varias veces al día, y que cada fusión dispare automáticamente la compilación y la batería de pruebas. Su objetivo es detectar conflictos e incompatibilidades en horas, no en semanas.
La entrega continua (Continuous Delivery) extiende la CI: cada cambio que supera las pruebas se empaqueta y queda listo para desplegar en cualquier momento, pero el salto a producción requiere una aprobación manual. El despliegue continuo (Continuous Deployment) elimina incluso esa aprobación: si todas las comprobaciones pasan, el cambio llega solo a producción. La diferencia entre los dos «CD» —entrega frente a despliegue— es precisamente ese botón humano, y elegir uno u otro es una decisión de gobierno y riesgo, no técnica.
Anatomía de un pipeline: las etapas que no deben faltar
Un pipeline maduro encadena etapas en las que el coste de fallar crece y el «radio de daño» disminuye si se falla pronto. Las etapas canónicas son:
- Build: compilación y construcción del artefacto (binario, imagen de contenedor, paquete). Debe ser reproducible y partir de un estado limpio.
- Pruebas unitarias y de integración: validan la lógica de negocio. Aquí se mide la cobertura, aunque la cobertura por sí sola no garantiza calidad.
- Análisis estático y de seguridad (SAST/SCA): linters, escaneo de dependencias vulnerables y análisis de código. Es el lugar para «desplazar la seguridad a la izquierda» (shift-left security).
- Empaquetado y publicación de artefactos: versionado inmutable de la imagen en un registro de contenedores.
- Despliegue por entornos: primero a staging, después a producción, idealmente con estrategias de bajo riesgo como blue-green o canary.
Un principio de oro recorre todo el pipeline: construir el artefacto una sola vez y promocionar exactamente ese artefacto entre entornos. Recompilar para producción introduce el riesgo de que lo desplegado no sea lo probado.
GitHub Actions frente a GitLab CI: cómo se materializa
Ambas plataformas describen el pipeline como código YAML versionado junto a la aplicación, lo que cumple el principio de pipeline-as-code. En GitHub Actions los flujos viven en .github/workflows/, se organizan en jobs y steps, y reutilizan bloques de la comunidad mediante actions. En GitLab CI la configuración reside en .gitlab-ci.yml, se estructura en stages y jobs, y aprovecha la integración nativa con el registro de contenedores y el seguimiento de incidencias del propio GitLab.
| Aspecto | GitHub Actions | GitLab CI/CD |
|---|---|---|
| Fichero de configuración | .github/workflows/*.yml | .gitlab-ci.yml |
| Unidad de organización | Jobs y steps | Stages y jobs |
| Reutilización | Marketplace de actions | Plantillas include y CI components |
| Ejecutores | GitHub-hosted o self-hosted runners | Shared o specific runners |
| Modelo integrado | Ecosistema GitHub + packages | Plataforma DevOps completa de un único proveedor |
La elección rara vez depende de la capacidad técnica —ambas cubren el ciclo completo— sino del ecosistema donde ya vive el equipo y de la preferencia por una plataforma todo en uno (GitLab) frente a un modelo modular y abierto (GitHub).
Infraestructura como código y gestión de secretos
Un pipeline que despliega necesita infraestructura sobre la que desplegar, y esa infraestructura también debe ser código. Herramientas como Terraform (declarativa, orientada a aprovisionar recursos cloud) o Ansible (orientada a configurar máquinas) permiten que el entorno sea reproducible, versionado y revisable mediante pull requests. La consecuencia operativa es enorme: recrear un entorno completo deja de ser un ritual manual de horas y pasa a ser la ejecución de un plan.
El punto más delicado del pipeline es la gestión de secretos. Credenciales, claves de API y tokens nunca deben escribirse en el YAML ni en el repositorio. Se almacenan en almacenes específicos —GitHub Secrets, variables protegidas de GitLab, o gestores como HashiCorp Vault— y se inyectan en tiempo de ejecución con el mínimo privilegio necesario. Tendencias actuales como la autenticación OIDC permiten que el pipeline obtenga credenciales temporales del proveedor cloud sin almacenar ningún secreto de larga vida.
Junto a los secretos, dos prácticas elevan la madurez del pipeline. La primera es el almacenamiento del estado de la infraestructura de forma remota y bloqueada (por ejemplo, el state de Terraform en un bucket con bloqueo), de modo que dos ejecuciones simultáneas no corrompan el entorno. La segunda es el uso de entornos efímeros de revisión: cada pull request levanta automáticamente una copia desechable de la aplicación donde revisar el cambio en vivo, que se destruye al fusionar. Así la revisión deja de ser una lectura de código en abstracto y pasa a ser una comprobación funcional real, sin contaminar entornos compartidos ni dejar recursos huérfanos consumiendo presupuesto.
Métricas DORA: cómo saber si el DevOps funciona
La investigación DORA (DevOps Research and Assessment) propuso cuatro métricas que correlacionan con el rendimiento de la entrega de software, hoy referencia del sector:
- Frecuencia de despliegue: cada cuánto se lleva código a producción.
- Tiempo de entrega del cambio (lead time for changes): cuánto tarda un commit en llegar a producción.
- Tasa de fallos del cambio (change failure rate): qué porcentaje de despliegues provoca una degradación que exige remediación.
- Tiempo de restauración del servicio (time to restore): cuánto se tarda en recuperarse de un incidente.
El matiz clave es que estas métricas no se contraponen: los equipos de alto rendimiento despliegan más a menudo y con menor tasa de fallos. La velocidad bien hecha es la consecuencia de la estabilidad, no su enemiga. Conviene además leerlas como un conjunto y nunca de forma aislada: optimizar solo la frecuencia de despliegue sin vigilar la tasa de fallos y el tiempo de restauración produce equipos que entregan rápido pero rompen producción a menudo, lo que destruye la confianza y acaba ralentizando la entrega real. El equilibrio entre las cuatro métricas es, en sí mismo, el indicador de salud del proceso.
Errores comunes al implantar CI/CD
- Pruebas lentas o intermitentes (flaky). Un pipeline que tarda cuarenta minutos o que falla aleatoriamente erosiona la confianza y empuja a la gente a saltárselo.
- Recompilar por entorno. Generar artefactos distintos para staging y producción rompe la garantía de que se despliega lo que se probó.
- Secretos en el repositorio. El error de seguridad más frecuente y más caro de revertir, porque un secreto filtrado debe rotarse aunque se borre del historial.
- Desplegar sin estrategia de reversión. Sin rollback automático ni feature flags, cualquier despliegue defectuoso se convierte en una incidencia prolongada.
- Automatizar el caos. Si el proceso manual está roto, automatizarlo solo produce fallos más rápido; primero se ordena el proceso, después se automatiza.
Preguntas frecuentes
¿Cuál es la diferencia real entre entrega continua y despliegue continuo?
En la entrega continua el software queda listo para producción de forma automática, pero el salto final lo autoriza una persona. En el despliegue continuo no hay aprobación manual: si todas las pruebas pasan, el cambio llega solo a producción. La elección depende de la madurez de las pruebas y del apetito de riesgo del negocio.
¿Necesito contenedores para hacer CI/CD?
No es obligatorio, pero los contenedores (Docker) facilitan enormemente la reproducibilidad: el mismo artefacto se ejecuta igual en el portátil del desarrollador, en el pipeline y en producción. Sin contenedores también se puede, pero aumenta el riesgo de diferencias entre entornos.
¿Qué son las estrategias blue-green y canary?
Blue-green mantiene dos entornos idénticos y conmuta el tráfico de uno (la versión antigua) a otro (la nueva) de golpe, con reversión instantánea. Canary libera la nueva versión a un pequeño porcentaje de usuarios, observa métricas y amplía gradualmente si todo va bien. Ambas reducen el radio de daño de un despliegue defectuoso.
¿Por dónde empieza una empresa sin ningún pipeline?
Por la integración continua básica: automatizar build y pruebas en cada fusión a la rama principal. Una vez que esa base es fiable, se añaden análisis de seguridad, empaquetado de artefactos y, por último, el despliegue automatizado por entornos.
Conclusión
El valor de un pipeline de CI/CD no se mide en lo sofisticado que sea el YAML, sino en una propiedad concreta: que llevar un cambio a producción deje de ser un acontecimiento estresante y se convierta en una rutina aburrida y segura. Cuando construir una sola vez, probar de forma exhaustiva, gestionar los secretos fuera del código y desplegar con estrategias reversibles forman parte del flujo normal de trabajo, las métricas DORA mejoran solas y el equipo recupera el tiempo que antes gastaba apagando fuegos. Esa es la promesa real de DevOps: no desplegar más deprisa por deprisa, sino eliminar el miedo al despliegue. En Summum Sistemas diseñamos e implantamos pipelines en GitHub Actions y GitLab CI adaptados a la madurez de cada equipo.