1. DevOps
Prácticas, herramientas y cultura para automatizar y unificar desarrollo, operaciones y entrega continua de software.
1.1 🎯 ¿Qué es DevOps?
Qué: Cultura y conjunto de prácticas que combinan desarrollo (Dev) y operaciones (Ops) para entregar software de forma rápida, confiable y segura.
Por qué: Reduce tiempo de entrega, aumenta frecuencia de deploys, mejora calidad, acelera recuperación ante fallos.
Quién: Developers, DevOps Engineers, SREs, Platform Engineers.
Costo: Inversión inicial alta (3-6 meses setup), ROI continuo en velocidad y estabilidad.
1.2 🔄 CI/CD (Continuous Integration / Continuous Delivery)
What: Automatizar integración, testing y despliegue de código.
Why: Detecta problemas temprano, reduce "works on my machine", deploys predecibles.
| Componente | Qué | Por qué | Cuándo | Cómo | Herramientas |
|---|---|---|---|---|---|
| CI | Integrar cambios frecuentemente con tests automáticos | Detectar conflictos/bugs rápido | Cada push, cada PR | Pipeline: checkout → build → test → report | GitHub Actions, GitLab CI, Jenkins |
| CD | Deploy automático a staging/producción | Reducir errores humanos, entregas rápidas | Tras merge a main (staging), manual/automático (prod) | Pipeline: build → test → package → deploy | Argo CD, Spinnaker |
| Pipelines | Secuencia de pasos automatizados | Reproducibilidad, auditoría | Definir en código (YAML) | Stages paralelos, artifacts entre stages | Tekton, CircleCI |
| Artifacts | Empaquetado versionado de código | Desplegar mismo artifact en todos los ambientes | Tras build exitoso | Docker images, JARs, tarballs con SHA | Artifactory, Nexus |
| Gates | Validaciones obligatorias pre-deploy | Prevenir deploys rotos | Antes de producción | Tests pasan, cobertura >80%, security scan OK | GitHub Branch Protection, GitLab Protected Branches |
1.3 🏗️ IaC (Infrastructure as Code)
What: Gestionar infraestructura mediante código versionado.
Why: Reproducibilidad, auditoría, disaster recovery rápido.
| Herramienta | Qué | Por qué | Cuándo | Cómo |
|---|---|---|---|---|
| Terraform | Provisionar infraestructura multi-nube | Agnóstico de proveedor, state management | Infraestructura compleja, multi-cloud | HCL (.tf), plan → apply, state en S3/Terraform Cloud |
| Pulumi | IaC en lenguajes generales (TS, Python, Go) | Reutilizar lógica de programación | Equipos con fuerte background dev | Código TypeScript/Python, pulumi up |
| Ansible | Configuración de servidores (CM) | Agentless, playbooks legibles | Configurar VMs, on-prem | YAML playbooks, SSH, idempotente |
| Crossplane | Provisionar infra desde Kubernetes | Unificar modelo de gestión | K8s-native environments | Custom Resources (CRDs), control loops |
1.4 📦 Contenedores y Orquestación
What: Empaquetar apps con sus dependencias, ejecutar en cualquier lado.
Why: "Funciona en mi máquina" → "Funciona en producción", escalabilidad.
| Tecnología | Qué | Por qué | Cuándo | Cómo |
|---|---|---|---|---|
| Docker | Crear y ejecutar contenedores | Portabilidad, aislamiento | Toda app moderna | Dockerfile → docker build → docker run |
| Kubernetes | Orquestar contenedores a escala | Auto-healing, scaling, rolling updates | Producción con >3 servicios | Deployments, Services, Ingress, HPA |
| Helm | Gestión de paquetes para K8s | Reutilizar manifests, versionado | Apps K8s complejas | Charts (templates YAML), helm install |
| Podman | Alternativa a Docker sin daemon | Seguridad (rootless), compatible Docker | Entornos restrictivos | CLI compatible con Docker |
1.5 🚀 Patrones de Despliegue
What: Estrategias para liberar código minimizando riesgo.
| Patrón | Qué | Por qué | Cuándo | Cómo |
|---|---|---|---|---|
| Rolling | Actualizar pods/instancias progresivamente | Alta disponibilidad, rollback fácil | Siempre | K8s actualiza 1 pod, espera health check, sigue |
| Blue-Green | Dos entornos: blue (actual), green (nuevo) | Zero downtime, rollback instantáneo | Apps críticas | Cambiar tráfico de blue a green tras validación |
| Canary | Liberar a % pequeño de usuarios | Detectar problemas antes de 100% | Features arriesgadas | 5% tráfico → monitor → 25% → 50% → 100% |
| Feature Flags | Activar/desactivar features sin redeploy | Desplegar desacoplado de lanzamiento | Releases coordinados, A/B testing | Flags en DB/config, evaluar en runtime |
| Shadow | Ejecutar nueva versión sin exponer | Comparar outputs sin riesgo | Cambios críticos (ML models) | Traffic replicado a ambas versiones, solo actual responde |
| Recreate | Detener todo, desplegar nuevo | Simplicidad máxima | Entornos no críticos, mantenimiento | kubectl delete → kubectl apply |
1.6 🔒 GitOps
What: Git como única fuente de verdad para infraestructura y configuración.
Why: Auditoría completa, rollback vía git revert, declarativo.
How:
- Definir estado deseado en Git (YAML)
- Operator detecta drift (diferencia estado real vs deseado)
- Operator aplica cambios automáticamente
Herramientas: Argo CD, Flux, Jenkins X
1.7 🛡️ Seguridad en CI/CD
| Práctica | Qué | Por qué | Cómo | Herramientas |
|---|---|---|---|---|
| SAST | Static Application Security Testing | Detecta vulnerabilidades en código | Escanear código en CI | SonarQube, Checkmarx |
| DAST | Dynamic Application Security Testing | Detecta vulnerabilidades en runtime | Probar app desplegada | OWASP ZAP, Burp Suite |
| Dependency Scan | Escanear librerías por CVEs | Actualizar dependencias vulnerables | Analizar package.json, pom.xml |
Snyk, Dependabot |
| Container Scan | Escanear imágenes Docker | Evitar desplegar vulnerabilidades | Escanear antes de push a registry | Trivy, Clair |
| Secrets Management | No hardcodear credenciales | Prevenir leaks en Git | Variables de entorno, secrets managers | Vault, AWS Secrets Manager |
1.8 📊 Métricas DORA (DevOps Research and Assessment)
| Métrica | Qué | Elite | High | Medium | Low |
|---|---|---|---|---|---|
| Deployment Frequency | Con qué frecuencia se deploya a prod | On-demand (múltiples por día) | Entre 1 día y 1 semana | Entre 1 semana y 1 mes | < 1 vez al mes |
| Lead Time for Changes | Tiempo desde commit hasta producción | < 1 hora | < 1 día | < 1 semana | > 1 semana |
| MTTR (Mean Time To Recover) | Tiempo para restaurar servicio tras fallo | < 1 hora | < 1 día | < 1 semana | > 1 semana |
| Change Failure Rate | % de deploys que causan fallo | 0-15% | 30% | 45% | > 45% |
Objetivo: Alcanzar niveles High o Elite para ser competitivos.
1.9 🔧 Herramientas Clave por Fase
1.9.1 Build & Test
1.9.2 CI/CD
1.9.3 Container Registry
1.9.4 Orchestration
1.10 🚫 Anti-patrones
| Anti-patrón | Problema | Solución |
|---|---|---|
| Snowflake Servers | Servidores únicos configurados manualmente | IaC + contenedores inmutables |
| Config Drift | Entornos staging ≠ producción | GitOps, IaC, identical configs |
| Manual Deploys | Error humano, no reproducible | CI/CD full automation |
| Long-lived Branches | Integration hell | Trunk-based development, feature flags |
| Shared CI Server | Builds lentos, colas | Runners paralelos, caching |