Saltar a contenido

DevOps: la cultura detrás del pipeline

Qué es, qué problema resuelve y en qué se diferencia de CI/CD.

¿Qué es DevOps?

Una forma de trabajo en la que quienes desarrollan y quienes operan el software comparten objetivos, herramientas y responsabilidad sobre lo que está en producción.

El nombre viene de juntar Development y Operations, los dos equipos que tradicionalmente estaban separados: uno escribía el código y el otro lo mantenía corriendo.

Dimensión Qué implica
Personas Un mismo equipo construye, despliega y responde cuando algo falla: «you build it, you run it»
Procesos Cambios pequeños y frecuentes, automatización de lo repetitivo, retroalimentación rápida desde producción
Herramientas Git, Docker, CI/CD, Kubernetes, monitoreo. Son el medio, nunca el objetivo

Lo que DevOps no es

  • No es un cargo. El aviso que dice «se busca un DevOps» en realidad busca a alguien de infraestructura o de plataforma.
  • No es un equipo aparte. Crear un «equipo DevOps» entre Dev y Ops reconstruye exactamente el muro que se quería quitar.
  • No es una herramienta. Instalar Jenkins, Kubernetes o GitHub Actions no vuelve DevOps a una organización.

¿Para qué sirve? El muro entre Dev y Ops

El problema que origina todo esto es un conflicto de incentivos:

flowchart LR
    D["Desarrollo<br/>quiere cambiar:<br/>entregar funcionalidades nuevas"] --- M["🧱 El muro"]
    M --- O["Operación<br/>quiere estabilidad:<br/>que nada se caiga"]

Cuando los dos objetivos se persiguen por separado aparecen siempre los mismos síntomas:

  • Despliegues grandes y poco frecuentes, porque cada uno es un evento de riesgo.
  • Culpas cruzadas: «el código está mal» contra «el servidor está mal configurado».
  • Conocimiento concentrado en una persona que es la única que sabe desplegar.
  • Miedo a publicar, que se traduce en publicar menos, lo que hace cada publicación más grande y más riesgosa.

DevOps alinea los dos objetivos: el equipo que escribe el cambio es el mismo que lo despliega y el que recibe la alerta a medianoche. Esa responsabilidad compartida es lo que hace que valga la pena automatizar, monitorear y escribir pruebas.

Cómo se mide: las cuatro métricas DORA

En lugar de discutir si un equipo «hace DevOps», el informe State of DevOps propone medir cuatro cosas:

Métrica Pregunta que responde
Frecuencia de despliegue ¿Cada cuánto llevamos cambios a producción?
Tiempo de entrega ¿Cuánto pasa entre el commit y que esté corriendo?
Tasa de fallos en el cambio ¿Qué porcentaje de despliegues provoca un incidente?
Tiempo de recuperación ¿Cuánto tardamos en restablecer el servicio cuando algo falla?

El resultado contraintuitivo

Los equipos que despliegan más seguido son también los que menos fallan. No es una paradoja: cada cambio es pequeño, el error es fácil de localizar y volver atrás cuesta poco. Desplegar poco no reduce el riesgo, lo acumula.

Diferencia y unión con CI/CD

DevOps CI/CD
Qué es Una cultura y una forma de organizar el trabajo Una práctica técnica: un pipeline automatizado
Alcance Todo el ciclo: idea, código, operación y monitoreo Del commit al despliegue
Se implementa Con acuerdos, responsabilidades y hábitos Con archivos YAML en el repositorio
Se mide con Frecuencia, tiempo de entrega, fallos, recuperación Builds verdes y duración del pipeline
Ejemplo El equipo es dueño de su servicio en producción .github/workflows/build.yml

Dónde se unen: CI/CD es la forma más visible de practicar DevOps. La relación funciona en los dos sentidos:

  • Sin automatización, DevOps se queda en un discurso: nadie puede ser responsable de producción si desplegar cuesta una tarde.
  • Sin cultura, el pipeline se convierte en un script que nadie mantiene: se rompe, alguien lo desactiva «mientras tanto» y se vuelve al despliegue manual.

Prácticas que lo hacen concreto

Aterrizado al proyecto del curso, «hacer DevOps» significa estas cosas:

Práctica En el proyecto
Todo en el repositorio Código, Dockerfile, manifiestos k8s/ y el workflow viven juntos y se revisan en un pull request
Infraestructura como código El servidor no se configura a mano: se describe en Kubernetes o Docker Compose
Automatizar lo repetitivo GitHub Actions construye y despliega sin que nadie entre al servidor
Pruebas como red de seguridad Pruebas unitarias y análisis estático en cada push
Configuración fuera del código Secretos en variables de entorno o Secret, nunca en el repositorio
Observar lo que pasa Logs y readinessProbe/livenessProbe para saber si la aplicación está sana
Responsabilidad compartida Quien rompe el main lo arregla; desplegar no es tarea de una sola persona

Preguntas frecuentes

¿Se puede tener CI/CD sin cultura DevOps?

Sí, y pasa a menudo. El resultado típico: un pipeline que alguien montó, que lleva meses en rojo y que el equipo ignora.

¿Y cultura DevOps sin CI/CD?

También, pero no escala. La buena intención de ser responsable de producción se agota cuando cada despliegue cuesta horas de trabajo manual.

¿Dónde entra la seguridad?

En la misma idea, llevada un paso más allá: DevSecOps es incorporar las comprobaciones de seguridad al pipeline (análisis de dependencias, secretos filtrados, escaneo de imágenes) en vez de dejarlas para una revisión al final.

Referencias