DevOps y GitOps: pipeline CI/CD, calidad y versiones reproduci­bles

Las versiones fiables nacen de cuatro piezas: un pipeline CI/CD que automatiza cada paso desde el commit hasta el despliegue, infraestructura como código que hace reproducibles los entornos, credenciales protegidas y un plan de rollback ensayado. GitOps une estas piezas al convertir Git en la única fuente de referencia de la aplicación y de la infraestructura.

¿Una versión el viernes por la tarde? En muchas empresas, solo imaginarlo provoca inquietud: demasiadas veces ha habido subidas manuales, configuraciones olvidadas y tardes interminables. Este artículo muestra de qué fases consta un pipeline sólido, cómo separar con limpieza entornos y credenciales, qué puede hacer para proteger la cadena de suministro de software, cómo es un plan de rollback y cómo medir si su entrega mejora.

Qué significan DevOps y GitOps en concreto

DevOps describe una forma de trabajar en la que desarrollo y operaciones comparten la responsabilidad del software, desde el primer commit hasta el funcionamiento estable. La automatización no es un fin en sí misma, sino que garantiza que los pasos recurrentes se ejecuten siempre igual.

GitOps va un paso más allá: el repositorio Git es la fuente de referencia del código de la aplicación y de la infraestructura. Cada cambio, ya sea una función nueva o una configuración de servidor modificada, pasa por un pull request, se revisa y después se despliega automáticamente. Según los principios de OpenGitOps, el estado objetivo se describe de forma declarativa, se almacena versionado e inmutable, se aplica automáticamente y se concilia de forma continua con el estado real. Así se puede saber en cualquier momento quién cambió qué y cuándo, y las desviaciones destacan. GitOps está muy extendido sobre todo en entornos Kubernetes con herramientas como Argo CD o Flux, pero el principio también vale sin Kubernetes.

Término	Pregunta a la que responde	Herramientas típicas
Integración continua (CI)	¿Pasa cada cambio automáticamente por compilación y pruebas?	GitHub Actions, GitLab CI/CD, Azure DevOps, Jenkins
Entrega/despliegue continuo (CD)	¿Cómo llega un artefacto verificado al entorno: con aprobación o de forma totalmente automática?	las mismas plataformas, Argo CD, Flux
Infraestructura como código	¿Cómo se describen de forma reproducible servidores, redes y permisos?	Terraform u OpenTofu, Bicep, Pulumi, Ansible
GitOps	¿Es Git la fuente de referencia y una herramienta concilia el estado real?	Argo CD, Flux, flujos con pull requests

Los componentes de un pipeline CI/CD

Un pipeline CI/CD es una cadena de comprobaciones automatizadas. Cada fase debe superarse antes de que empiece la siguiente. Este orden ha dado buen resultado:

1. Compilación: el código se compila o empaqueta, de forma idéntica en cada ejecución.
2. Análisis estático: linters y análisis de código detectan problemas de estilo y estructura antes de que una persona deba buscarlos en la revisión.
3. Pruebas unitarias: pruebas pequeñas y rápidas comprueban funciones individuales.
4. Pruebas de integración: donde tiene sentido, se prueba la interacción con la base de datos, las interfaces u otros servicios.
5. Análisis de seguridad: se comprueba si las dependencias tienen vulnerabilidades conocidas y si el código contiene credenciales subidas por error.
6. Artefacto: el resultado se almacena con versión, por ejemplo como imagen de contenedor o paquete.
7. Despliegue en preproducción (staging): el artefacto se ejecuta en un entorno similar a producción, donde se lanzan pruebas de aceptación y pruebas de humo.
8. Aprobación y producción: manual, por una persona responsable (entrega continua), o automática cuando todas las comprobaciones están en verde (despliegue continuo).

El tiempo de ejecución no es un detalle: cuanto más rápido es el feedback, antes corrigen los desarrolladores los errores, mientras aún tienen el tema en la cabeza. Por eso, la ruta rápida de verificación, con compilación, análisis y pruebas unitarias, debería durar en lo posible solo unos minutos. Las pruebas más costosas pueden paralelizarse, acelerarse con caché o trasladarse a ejecuciones posteriores. Para las interfaces son un buen complemento las pruebas de contrato, como describe el artículo API REST con OpenAPI.

Branching: lo sencillo supera a lo complicado

Los modelos de ramas complejos, con muchas ramas de larga vida, suelen provocar fusiones dolorosas. Han demostrado su valor las ramas de funcionalidad de corta vida que se integran en una rama principal protegida mediante pull requests con revisión de código. Los cambios directos en la rama principal están bloqueados y la fusión exige que las comprobaciones del pipeline tengan éxito. Las funciones inacabadas permanecen desactivadas con feature flags, de modo que la rama principal siempre se pueda publicar.

GitOps y entornos bien separados

Infraes­truc­tura como código

Servidores, bases de datos, redes y permisos se describen y versionan con herramientas como Terraform, su fork de código abierto OpenTofu o Bicep. La vista previa de los cambios debe estar en el pull request para que los revisores vean lo que cambia realmente. Esto reduce el “drift”, es decir, las diferencias graduales entre entornos que nadie puede explicar ya, sobre todo si se evitan las intervenciones manuales. Más sobre el principio en nuestro glosario, bajo infraestructura como código.

Rutas de promoción claras

Defina rutas fijas desde el desarrollo, pasando por preproducción, hasta producción. Es importante que se traspase el mismo artefacto ya probado y que no se recompile para cada entorno. Lo único que difiere entre entornos es la configuración. Lo que funcionó en preproducción es, por tanto, exactamente lo que sale a producción.

Las credenciales no pertenecen al repositorio

Las contraseñas, las claves de API y los certificados no tienen cabida en el código. Se guardan en un gestor de secretos como HashiCorp Vault o en el servicio de secretos de su proveedor de nube, o en las variables protegidas de la plataforma CI, y solo se inyectan en tiempo de ejecución. Cuando los secretos deben estar en el repositorio, se almacenan cifrados, por ejemplo con SOPS. Si el pipeline accede a la nube, un inicio de sesión federado mediante OpenID Connect sustituye a las claves de larga duración. Un escáner avisa de los secretos subidos por error y las claves que hayan quedado expuestas se cambian de inmediato.

Proteger la cadena de suministro de software

El propio pipeline es un objetivo de ataque, porque tiene acceso al código, a las credenciales y a producción. Algunas medidas cuestan poco y aportan mucho:

• Fijar las dependencias con lockfiles y actualizarlas con regularidad con herramientas como Dependabot o Renovate
• Fijar las acciones y plugins de terceros del pipeline a versiones fijas o a hashes de commit
• Conceder los permisos del pipeline según el principio de mínimos privilegios y permitir el acceso a producción solo desde entornos protegidos
• Firmar los artefactos, por ejemplo con Sigstore/cosign, y generar para cada versión una lista de materiales de software (SBOM)

Quien comercializa software como producto en la UE debería comprobar además si le afecta el Reglamento de Ciberresiliencia (Cyber Resilience Act). Exige a los fabricantes, entre otras cosas, una gestión de vulnerabilidades y una lista de materiales de los componentes. Las obligaciones de notificación de vulnerabilidades explotadas activamente se aplican desde el 11 de septiembre de 2026; las demás obligaciones, a partir del 11 de diciembre de 2027. Este artículo no sustituye el asesoramiento jurídico.

El plan de rollback: cuando algo sale mal

Ni el mejor pipeline evita todos los errores. Lo decisivo es lo rápido que pueda reaccionar. Las estrategias se diferencian en esfuerzo y en vía de retorno:

Estrategia	Principio	Ventaja	Coste
Actualización progresiva (rolling)	las instancias se sustituyen una tras otra	pocos recursos adicionales	la vuelta atrás tarda; dos versiones conviven brevemente
Blue/green	dos entornos idénticos y el tráfico se conmuta	retorno inmediato conmutando	recursos duplicados durante el cambio
Canary	una pequeña parte del tráfico va primero a la versión nueva	riesgo limitado, prueba con tráfico real	requiere métricas y control del tráfico
Feature flags	las funciones se activan mediante un interruptor	entrega y activación separadas, desactivación sin nuevo despliegue	hay que limpiar los flags

En todos los casos: observe con especial atención la tasa de errores y los tiempos de respuesta tras el despliegue, prevea para ello una ventana fija (por ejemplo, de 30 a 60 minutos) y fije de antemano los umbrales a partir de los cuales se revierte. Ensaye el rollback con regularidad, no solo en caso de emergencia.

Migraciones de base de datos retro­compati­bles

La trampa más habitual del rollback es la base de datos. Ha dado buen resultado el patrón “ampliar, migrar, limpiar”: primero el esquema solo se amplía, por ejemplo con una columna nueva, de modo que la versión antigua y la nueva puedan trabajar con él. Después se cambia la aplicación y se migran los datos. Solo en una versión posterior se elimina lo que ya no hace falta. Así el rollback sigue siendo posible en todo momento.

Métricas: cómo reconocer un buen pipeline

Se puede medir si la inversión compensa. La investigación sobre DevOps nombra cuatro métricas, las llamadas métricas DORA (que no deben confundirse con el reglamento europeo DORA para el sector financiero):

• Tiempo de entrega: ¿cuánto se tarda desde el commit hasta producción?
• Frecuencia de despliegue: ¿con qué frecuencia salen los cambios a producción?
• Tasa de fallos de cambios: ¿qué proporción de los despliegues causa problemas?
• Tiempo de recuperación: ¿con qué rapidez se restablece el funcionamiento normal tras un fallo?

Lo importante es la tendencia del propio equipo, no la comparación con otros. Haga que los valores se calculen automáticamente a partir del pipeline y del sistema de tickets, para que no se conviertan en estimaciones. Los pipelines lentos y los hotfixes frecuentes son, por cierto, a menudo un síntoma de deuda técnica.

Paso a paso hacia su propio pipeline

1. Registrar la situación actual: ¿cómo se compila, se prueba y se entrega hoy, y quién sabe hacerlo?
2. Automatizar la compilación y el despliegue en preproducción.
3. Añadir el análisis estático y las pruebas unitarias como fases obligatorias y proteger la rama principal.
4. Integrar el análisis de dependencias y retirar las credenciales del repositorio.
5. Describir la infraestructura como código paso a paso, empezando por el entorno con mayor riesgo de cambios.
6. Configurar la monitorización con umbrales para la tasa de errores y la latencia.
7. Ensayar el rollback con regularidad y seguir las métricas DORA como tendencia.

Un escenario típico de la práctica

Una empresa mediana opera un portal de clientes. Un único desarrollador sube las versiones nuevas al servidor mediante archivos y hace a mano los cambios en la base de datos. Si falta, nadie se atreve a publicar una versión. Los errores a menudo solo se descubren cuando llaman los clientes.

El camino para salir de esta dependencia empieza poco a poco: primero se traduce el proceso existente a un pipeline que compila automáticamente y entrega en un entorno de preproducción. Después se añaden pruebas y el análisis de dependencias, y luego la descripción de los servidores como código y una monitorización con alertas. Paso a paso surge así un proceso en el que cualquier miembro del equipo puede lanzar una versión, de forma trazable, repetible y con una vía de retorno clara. Cómo afronta además la plataforma una carga creciente se explica en Escalado en la nube para plataformas.

Errores típicos

• Las pruebas inestables se ignoran o se repiten hasta que salen en verde, y la confianza en el pipeline disminuye.
• Se compila de nuevo para cada entorno, de modo que en producción se ejecuta algo distinto de lo que se probó en preproducción.
• Los cambios en el servidor o en la consola de la nube se hacen a mano y el código ya no conoce el estado real.
• La propia configuración del pipeline se modifica sin revisión.
• El rollback solo existe sobre el papel y nunca se ha probado.

Cómo le ayuda Nano Concepts

Si desea modernizar su entrega, le apoyamos con DevOps y CI/CD, desde el primer borrador del pipeline hasta la operación continua. En la primera consulta gratuita aclaramos en qué punto está hoy su entrega y qué paso aportará primero el mayor beneficio.