DevOps

Definición

DevOps es un enfoque cultural + técnico para entregar software de forma rápida y fiable, reduciendo silos entre desarrollo (Dev), operación (Ops) y QA mediante colaboración, visibilidad compartida y automatización (p. ej., CI/CD, IaC, observabilidad).
La idea práctica es: cambios pequeños, frecuentes y reversibles con feedback continuo.

Contexto

El RAW recorre la evolución que suele desembocar en DevOps:

• Cascada (Waterfall): equipos muy separados y fases secuenciales; el feedback llega tarde y aparecen “blame games”.
• Ágil (Agile): iteraciones más cortas y adaptación al cambio; mejora el desarrollo, pero no siempre resuelve el “handoff” y fricción Dev↔Ops.
• DevOps: se impulsa un cambio cultural y se incorpora automatización para que todos los equipos tengan la misma visibilidad y colaboren en el ciclo completo.
• Marco base del ciclo de vida: SDLC (Software Development Life Cycle).

Desarrollo (MIT-style)

1) Historia rápida: Cascada → Agile → DevOps (según RAW)

Modelo de cascada (años 70)

Características típicas:

• Roles separados por función (SysAdmins / Dev / QA).
• Flujo secuencial: se “pasa” el trabajo de un equipo al siguiente.
• Si algo falla, es frecuente el “intercambio de culpas” y la acumulación de tareas/bugs.

Modelo ágil (a partir de ~2000)

El RAW menciona el Manifiesto Ágil y sus valores, orientados a:

• Feedback temprano.
• Colaboración.
• Capacidad de adaptación.

DevOps (2008–2009, DevOpsDays)

Según el RAW, DevOps surge como reacción a limitaciones prácticas (especialmente coordinación y entrega) y se populariza tras DevOpsDays.

Punto clave: DevOps busca integración cruzada entre equipos (Dev/Ops/QA) y automatización para:

• Reducir fricción y “handoffs”.
• Aumentar visibilidad y responsabilidad compartida.
• Hacer que la entrega sea rutinaria y observable.

2) DevOps como “bucle infinito” (según RAW)

El RAW representa DevOps como un bucle infinito (ciclo continuo) que conecta fases del ciclo de vida.

Interpretación práctica:

• No hay “final” real: despliegas, operas, aprendes (monitoring) y vuelves a planificar/cambiar.
• El objetivo no es “correr más”, sino correr con control (feedback + rollback + calidad).

3) Marco CALMS (Culture, Automation, Lean, Measurement, Sharing)

El RAW resume la adopción DevOps con CALMS (Jez Humble):

• Cultura: DevOps es un cambio cultural; pasar de releases grandes a trabajo en sprints/entregas pequeñas. Involucra dev, QA, producto y ops.
• Automatización: integración y despliegue automatizados; empezar por entrega continua y evolucionar a integración continua. Incluye configuración como código para builds por entorno.
• Lean: dividir tareas lo más posible, entregar una primera versión “lean” y mejorar con feedback.
• Medición: métricas para evaluar efectividad y mejora continua.
• Sharing: responsabilidad compartida del producto final entre equipos.

4) Prácticas y capacidades típicas (según RAW)

El RAW enumera herramientas/procesos que suelen sostener DevOps:

1. CI/CD

   • Integración frecuente de cambios + pruebas automatizadas.
   • Favorece cambios pequeños y repetibles, y reduce el coste de revertir.
   • Ejemplos de despliegue automatizado: Netlify y Argo CD.
   • Conecta directamente con seguridad en SSDLC/DevSecOps: ver Secure SDLC (SSDLC), DevSecOps.

2. Infraestructura como Código (IaC)

   • Gestionar y aprovisionar infraestructura mediante código y automatización.
   • Beneficios: consistencia, repetibilidad, auditabilidad de cambios.
   • Ejemplos mencionados en el RAW: Terraform, Vagrant.
   • Ver detalle: Infraestructura como codigo (IaC).

3. Gestión de la configuración

   • Mantener el estado deseado de la infraestructura y aplicar cambios de manera eficiente.
   • Configuración como código para definir builds por entorno y reducir errores.
   • Puede apoyarse en IaC.

4. Orquestación

   • Automatización de flujos de trabajo.
   • Permite respuestas rápidas ante eventos (p. ej., health checks fallidos) cuando hay monitorización.

5. Monitoreo

   • Recopilar datos de rendimiento/estabilidad para acelerar recuperación y análisis de causa raíz.
   • Es un habilitador directo de feedback al desarrollo.

6. Microservicios

   • Arquitectura por servicios pequeños con escalado/flexibilidad; suele combinarse con contenedores y orquestación.
   • Ver también Virtualization Fundamentals - Hypervisors, Containers, Kubernetes.

Operaciones en DevOps (según RAW):

• Autoservicio para devs (acceso bajo demanda a herramientas y entornos seguros).
• Estandarización de herramientas/procesos para reducir fricción y mejorar colaboración.
• Automatización extensible de tareas repetibles (p. ej., aprovisionar VMs con Terraform y registrar actividad).
• “X as Code” como norma (p. ej., Vagrant, Ansible): el código de operaciones debe versionarse, protegerse y mantenerse.

5) Declarativo vs imperativo (según RAW)

El RAW contrasta dos estilos comunes cuando automatizas:

• Declarativo: declaras el estado final esperado y el sistema converge hacia él.
• Imperativo/procedimental: defines pasos para llegar al estado final; puedes añadir “gates” (puertas) para aplicar cambios tras pasar checks.

Ejemplo conceptual (no específico de herramienta):

1
Declarativo: "Quiero 3 instancias, en estas subredes, con este SG".
2
Imperativo:  "Crea instancia A; configura X; valida; despliega; luego B…"

6) Métricas de DevOps (según RAW)

El RAW indica que, sin métricas, es difícil detectar bloqueos en despliegues o entender por qué aumentan los fallos. Las métricas clave responden preguntas sobre tiempos, frecuencia y estabilidad:

• MTTP (Mean Time to Production): tiempo entre el commit y la puesta en producción. Mejora con automatización y lotes pequeños, dando feedback rápido.
• Frecuencia de despliegue: cuántas veces se publica en producción (puede ser varias veces al día).
• Velocidad de despliegue: cuánto tarda una versión nueva en llegar a producción.
• Agilidad de despliegue: combinación de velocidad + frecuencia.
• Tasa de fallos de cambios: porcentaje de cambios en producción que requieren fixes urgentes (no cuenta fallos detectados antes del deploy). Prácticas que reducen MTTP suelen reducir esta tasa.
• MTTR (Mean Time to Recovery): tiempo medio de recuperación tras un incidente; requiere monitoreo, alertas y capacidad de rollback.

Notas prácticas del RAW:

• La frecuencia depende de pipelines con pruebas automatizadas y feedback continuo.
• El MTTR exige procesos y permisos claros para que Ops resuelva incidentes rápidamente.

Comunicar el riesgo: medir y reportar estas métricas facilita la aceptación de cambios. El “riesgo” varía por equipo (seguridad = probabilidad/impacto; ops = fallos en producción). Alinear definiciones mejora la colaboración (ver DevSecOps).

7) Ampliación: prácticas de fiabilidad que suelen acompañar DevOps (pendiente de validar)

Para que “entregar rápido” no aumente el riesgo operativo, en la práctica suelen aparecer:

• Rollback fiable (artefactos versionados, DB migrations controladas).
• Feature flags y despliegues graduales (canary / blue-green).
• Observabilidad (logs, métricas y trazas) y alertas accionables.
• Métricas DORA para medir desempeño de entrega (Deployment Frequency, Lead Time, Change Failure Rate, MTTR).

8) DevOps y seguridad (puente a DevSecOps)

El RAW enlaza DevOps con la idea de que la seguridad debe entrar temprano (“Shift Left”), lo que se formaliza como DevSecOps:

• Ver DevSecOps.
• Marco operativo en ciclo de vida: Secure SDLC (SSDLC).
• Seguridad especifica del pipeline: Seguridad en canalizaciones DevOps (CI-CD).

Ejemplos

Ejemplo 1 — Pipeline típico (simplificado)

• PR/MR → tests (unit/integration) → build artefacto → despliegue a staging → verificación (smoke) → despliegue a prod (gradual) → monitorización.

Ejemplo 2 — IaC como control de cambio

• Cambios de red/infra versionados (review + historial) → apply automatizado con validaciones → rollback si hay degradación.

Ejemplo 3 — Ejercicio del RAW (modelos por “feedback”)

Interpretación razonable (pendiente de validar con el material original del laboratorio):

• Cómic 1: Cascada (decisión inicial se mantiene; cambios tardíos).
• Cómic 2: Agile (se cambia rumbo en base a pruebas/feedback).
• Cómic 3: DevOps (más colaboración cruzada, nuevos parámetros de pruebas, ajuste continuo).

Pitfalls / Errores comunes

• Tratar DevOps como “comprar herramientas” sin cambio cultural (silos siguen igual).
• Automatizar sin observabilidad: despliegues rápidos, pero sin capacidad de detectar/diagnosticar.
• Falta de estrategia de rollback (cada incidente obliga a “parar todo”).
• Mezclar cambios enormes (“big bang”) en lugar de pequeños incrementos.

Diagrama

flowchart LR
P[Plan] --> C[Code]
C --> B[Build]
B --> T[Test]
T --> R[Release]
R --> D[Deploy]
D --> O[Operate]
O --> M[Monitor]
M --> P

Referencias

1. History of DevOps (Appknox): https://www.appknox.com/blog/history-of-devops
2. Agile Manifesto: http://agilemanifesto.org/
3. Atlassian — CALMS framework: https://www.atlassian.com/devops/frameworks/calms-framework
4. GitLab — MTTP métricas de entrega: https://about.gitlab.com/handbook/engineering/infrastructure/team/delivery/metrics.html
5. Netlify (deploy automation): https://www.netlify.com/
6. Argo CD (GitOps/CD): https://argoproj.github.io/cd/
7. Vagrant: https://www.vagrantup.com/
8. Ansible: https://www.ansible.com/