Sustituya “ojalá funcione”
por git push origin main.
Contenedores, pipelines de CI/CD, Kubernetes, infraestructura como código (IaC), observabilidad y automatización de releases: todo con un solo equipo. El desarrollador ejecuta “git push”; lint, pruebas, build, análisis de seguridad, push de la imagen y despliegue se encadenan automáticamente en minutos. Si algo falla, se revierte en 18 segundos. Con estándares DevOps alemanes.
La única forma de que un lanzamiento deje de ser un acontecimiento es la automatización disciplinada. Si quiere dejar de hacer guardias los viernes por la noche, está en el lugar correcto.
Publicar versiones con un “ojalá funcione” está agotando a su equipo.
Hablemos con honestidad de las cifras: un lanzamiento fallido no solo supone perder ingresos, también supone perder la confianza dentro del equipo. Estos son los cinco problemas más comunes que vemos.
Si una persona se conecta por SSH al servidor, descarga archivos y reinicia servicios, ese lanzamiento consume media jornada laboral. Si se omite un paso, se descubre el lunes. El despliegue previsto para el viernes por la tarde se alarga hasta la medianoche, y el ingeniero DevOps que debía librar esa noche, en realidad, no libra. A fin de mes este ciclo provoca agotamiento profesional (burnout) y, a fin de trimestre, renuncias. La solución: que sea el pipeline, y no una persona, quien pulse el botón de despliegue.
Cuando aparece un error después de un lanzamiento, el método “git revert + nuevo despliegue” lleva horas, no minutos. Durante esas horas no se pueden cobrar pagos ni crear registros, y el centro de llamadas se desborda. En un pipeline bien hecho, el rollback es un botón: la imagen anterior sigue en el registry, el Deployment de Kubernetes vuelve a la revisión previa y en 18 segundos todo está como antes. Para el rollback no hace falta un “plan”, sino un mecanismo.
Sin pipeline de CI, las pruebas no se ejecutan, porque siempre “hay prisa”. Cada pequeño error que surge en producción se acumula internamente, ya que nunca se notifica al cliente. Llega un momento en que los desarrolladores dejan de escribir código y pasan a responder solicitudes de soporte. La solución: que cada commit ejecute automáticamente todo el conjunto de pruebas, el análisis estático, la comprobación de tipos y el análisis de seguridad. El código que no las supere nunca se fusiona con main.
Hace 6 meses alguien cambió una configuración de nginx en el servidor de producción. Esa persona ya no está en la empresa. Nadie recuerda el cambio. Cuando instala un servidor nuevo, no puede reproducir el mismo comportamiento. La infraestructura como código (IaC) lo resuelve: Terraform, Pulumi, charts de Helm, manifiestos de Kubernetes; todo vive en git. Elimine un servidor y vuelva a crear uno idéntico en 8 minutos.
El sistema se cayó el sábado a las 03:14. Ninguna alerta en Slack; solo un cliente que el lunes por la mañana dice “no abre”. Se tardan 4 horas en encontrar los registros y 3 en entender la causa. DevOps de verdad significa esto: una alerta de Prometheus interrumpe su sueño el sábado a las 03:14, la causa se ve en el panel de Grafana, se ejecuta el runbook y el problema se resuelve en 12 minutos. El fin de semana sigue siendo fin de semana.
Una producción que se repara sola y mejora continuamente.
De la autorreparación de pods en Kubernetes a la IaC con Terraform, de las métricas DORA al rollback con un clic: a continuación mostramos cómo es realmente la operación diaria.
> pod web-7d4 listo en 2,1 s: el servicio continúa
resource "aws_eks_cluster" "prod" {
name = "partnerfy-prod"
version = "1.29"
role_arn = aws_iam_role.eks.arn
vpc_config {
subnet_ids = aws_subnet.priv[*].id
}
}
Plan: 14 to add, 0 to change, 0 to destroy.
Apply complete! Resources: 14 added.
Los cuatro indicadores clave de la salud de producción
Volver a la revisión anterior
kubectl rollout undo deployment/web
¿Para qué equipos marca la diferencia?
Llevamos años implementando DevOps en distintos sectores. Estos ocho perfiles son los equipos que más valor obtienen de nuestro trabajo.
SaaS con despliegues diarios
Solicitud del cliente → rama → revisión → en producción en 30 minutos. De 5 a 15 lanzamientos al día deberían ser lo normal.
E-commerce con pruebas A/B frecuentes
Feature flags que envían una variante al 5 % del tráfico, comparación automática de métricas y activación automática de la ganadora.
Fintech regulada
Cadena de aprobación, registro de auditoría, builds inmutables y separación de funciones. Pipeline listo para SOC2 y PCI.
B2B multitenant
Entorno por cliente, despliegue gradual, feature flags por tenant y supervisión de SLA por cliente.
CD a TestFlight / Play
Fastlane + Bitrise + automatización de la firma. Cada PR genera un IPA/AAB y lo distribuye a los dispositivos de prueba.
Startup que migra de monolito a servicios
Patrón strangler fig, service mesh (Istio/Linkerd) y transición gradual. Ambos mundos funcionan a la vez.
Gran empresa que moderniza sistemas heredados (legacy)
Contenerización de VM on-premise, migración del antiguo Jenkins a GitOps y de Active Directory a OIDC.
Agencia con 20+ repositorios de clientes
Plantillas de pipeline, repo-of-repos y gestión centralizada de secretos. Nuevo cliente = en producción en 2 horas.
Las diez capas de un stack DevOps.
En cada capa elegimos la herramienta más adecuada: en lugar de imponer una tecnología, buscamos el equilibrio entre los hábitos de su equipo y la sostenibilidad a largo plazo.
Contenerización
La aplicación se empaqueta en un Dockerfile, los builds multietapa generan imágenes mínimas y estas se envían automáticamente al registry. La misma imagen recorre dev → staging → prod.
Pipeline de CI
En cada commit: lint, pruebas unitarias y de integración, análisis estático, análisis de seguridad y build de la imagen. El código que falla no se fusiona.
Pipeline de CD
Enfoque GitOps: los manifiestos en git son la única fuente de verdad. ArgoCD sincroniza de forma continua; si detecta una desviación (drift), la corrige al instante o genera una alerta.
Implementación de Kubernetes
Gestionado (EKS/GKE/AKS) o autoalojado (k3s, kubeadm). El dimensionamiento del clúster, los node pools, el escalado automático y las políticas de red se diseñan en conjunto.
Charts de Helm
La aplicación se empaqueta en un chart parametrizado, con archivos de valores distintos para staging y prod. Actualizar de versión es un solo comando.
IaC con Terraform / Pulumi
Los recursos en la nube (VPC, RDS, S3, IAM) se definen como código. Ciclo plan → revisión → apply, estado remoto y bloqueado, y detección de desviaciones.
Gestión de secretos
Los archivos .env expuestos a filtraciones pasan a la historia. Con Vault o SOPS, los secretos quedan cifrados: el pipeline los obtiene dinámicamente en tiempo de ejecución y el desarrollador nunca los ve.
Observabilidad
Métricas (Prometheus) + registros (Loki) + trazas (Tempo) + paneles (Grafana). Alertas basadas en SLO y seguimiento del presupuesto de errores.
Guardias y alertas
¿Qué alerta despierta a quién? Rotaciones, escalado y alertas vinculadas a runbooks. Se acabó despertar a la persona equivocada a las 3 de la madrugada.
Análisis de seguridad
¿Una CVE en la imagen? ¿Una vulnerabilidad crítica en una dependencia? El pipeline detiene el build y propone una corrección automática en el PR. Seguridad shift-left.
Del pipeline antiguo al moderno en seis pasos.
No cambiamos toda la infraestructura de la noche a la mañana. Avanzamos por fases, sin interrumpir el negocio y contando con su equipo.
Auditoría del pipeline actual
Sprint de 2 semanas: cómo despliega hoy, qué pasos son manuales, qué servicio es un punto único de fallo y dónde se guardan los secretos.
Contenerizar las aplicaciones
Cada servicio recibe un Dockerfile, se reduce con builds multietapa y se envía a un registry. Dev y prod usan el mismo paquete.
Crear el pipeline de CI
Lint, pruebas, build y análisis automatizados. Al abrir un pull request, el bot devuelve verde o rojo en un plazo de 6 a 8 minutos.
Crear el pipeline de CD
GitOps con ArgoCD o Flux: staging automático en cada fusión y prod con una sola aprobación. Canary y rollback listos.
Conectar la observabilidad
Prometheus + Grafana + Loki. Se definen los SLO, se vinculan las reglas de alerta a los runbooks y se organiza la rotación de guardias.
Formar al equipo y traspasar
Taller de 2 días + documentación + conjunto de runbooks. Durante los 3 meses siguientes, soporte discreto: respondemos a sus preguntas en menos de una hora.
Las tecnologías que usamos en producción.
Antes y después, en cifras.
Jenkins → GitHub Actions + ArgoCD. Desde que el desarrollador fusiona, el cambio llega a producción en 12 minutos. Se acabó el miedo a desplegar los viernes por la noche.
Prometheus + PagerDuty + automatización de runbooks. La alerta llega antes de la caída, a la persona adecuada y con los pasos de resolución.
Builds inmutables, separación de funciones, trazabilidad de auditoría completa y secretos cifrados. Listos para la auditoría en 6 meses, sin un solo hallazgo del auditor.
Rolling updates + readiness probes + canary releases. Ni una sola interrupción visible para el cliente en 6 meses.
Fastlane + Bitrise + automatización de la firma. El equipo de QA ve el nuevo build en su dispositivo 4 minutos después de cada PR.
Flujo de trabajo reutilizable de GitHub Actions + CLI de arranque. Un cliente nuevo abre un repositorio y en 2 horas está en producción.
Lo que más nos preguntan
Respuesta corta: no. Si su escala es pequeña (de 1 a 3 servidores en una región, menos de 20 000 solicitudes/min), opciones como Docker Compose, AWS ECS Fargate, GCP Cloud Run, Fly.io o Render suponen mucha menos carga operativa. El valor real de Kubernetes aparece cuando se necesitan más de 5 servicios, varias regiones, escalado automático, estrategias avanzadas de despliegue (canary/blue-green) y una malla entre servicios. La decisión se toma conjuntamente en la reunión de auditoría; no haremos presión para “seguir la moda”. Si se pasa a K8s, recomendamos un servicio gestionado (EKS/GKE/AKS): no tendrá que administrar su propio clúster.
Normalmente no, al menos no de inmediato. Si Jenkins funciona, montamos el nuevo pipeline en paralelo (GitHub Actions / GitLab CI / Drone). Los servicios nuevos pasan por el nuevo pipeline y los antiguos se quedan en Jenkins. Ambos conviven durante 2 o 3 meses y, cuando el equipo ya se ha adaptado, se completa la migración. El enfoque de “tirarlo todo y reescribir desde cero” lleva 6 meses y deja todo a medias. Nuestra experiencia: la estrategia strangler fig siempre da mejores resultados. Si Jenkins realmente no es mantenible (versión antigua, exceso de plugins, nadie lo entiende), se lo diremos con franqueza.
Calendario típico: CI/CD básico (contenedores + pruebas + build + despliegue), 2-4 semanas. Incorporar Helm + Kubernetes, +2-4 semanas. Observabilidad completa (Prometheus + Grafana + Loki + alertas), +2-3 semanas. Gestión de la nube con Terraform/IaC, +3-6 semanas (según los recursos existentes). Total: 4 semanas para un equipo pequeño, 8-10 semanas para uno mediano y 12-16 semanas para una gran empresa. Lo importante: se avanza por fases, sin interrumpir el negocio. Empieza a obtener beneficios en cuanto termina la primera fase, y cada fase posterior agrega valor. No esperamos a un único momento de “todo listo”.
Sí, y lo consideramos parte del trabajo. Al completar la implementación se entrega: (1) documentación completa del pipeline en Markdown, (2) un taller práctico en vivo de dos días y (3) un periodo de acompañamiento de 30 días: observamos en segundo plano, el equipo toma la iniciativa y respondemos a las preguntas. En realidad, el día a día del desarrollador cambia muy poco: hace git push y el pipeline se ejecuta. La complejidad queda oculta en la infraestructura. Para la parte operativa (gestión de alertas, runbooks, rollback) organizamos una rotación de guardias. A los 3 meses, su equipo tiene la madurez necesaria para hacerse cargo del pipeline por sí solo.
Hay dos conceptos: (a) nuestra implementación + 3 meses de servicio de traspaso: el precio depende del proyecto, con cifras bajas de cuatro dígitos en un proyecto pequeño y cifras medias de cinco dígitos en uno corporativo (en EUR/USD, precio fijo). (b) Costo continuo de infraestructura: lo paga desde su propia cuenta en la nube; no actuamos como intermediarios. Cifras típicas de nube: SaaS pequeño, 200-600 EUR al mes; mediano, 1500-4000 EUR; corporativo, más de 8000. Nota importante: un diseño correcto ahorra entre el 30 y el 50 % de los costos en la nube (rightsizing, instancias spot, escalado automático). Por lo general, la inversión en DevOps se amortiza en 6 meses.
Sí. AWS, GCP, Azure, Hetzner y DigitalOcean: tenemos experiencia activa en producción con todos ellos. Terraform/Pulumi ofrecen una abstracción independiente del proveedor, y los manifiestos de Kubernetes funcionan en cualquier clúster. Muchas veces “multicloud” no es lo que realmente se necesita (la complejidad operativa se multiplica por 2,5): solemos recomendar una única nube principal, otra región (multirregión) y un segundo proveedor para la recuperación ante desastres. Si se requiere un verdadero multicloud (p. ej., datos de la UE en AWS y datos de EE. UU. en GCP), también lo implementamos. La elección de región por soberanía de datos (RGPD/KVKK) es un tema frecuente.
Sí. Hemos creado pipelines que cumplen ISO 27001, SOC2 Type II, PCI DSS, el RGPD y la KVKK (Ley turca n.º 6698 de Protección de Datos Personales). Lo que implementamos: builds inmutables (no se pueden alterar a posteriori), separación de funciones (quien escribe el código no puede desplegarlo), trazabilidad de auditoría completa (quién aprobó qué y cuándo), secretos cifrados (Vault/SOPS), cifrado en reposo y en tránsito, acceso a producción protegido con MFA y análisis de vulnerabilidades en cada build. La documentación para el auditor se entrega en plantillas listas para usar. Contamos con más de 6 casos en los que auditores independientes aprobaron pipelines creados por nosotros, y podemos compartir referencias.
Si se detecta un problema después de un lanzamiento, hay dos caminos. (1) Kubernetes rollout undo: la revisión anterior sigue en el historial del Deployment; con un comando o un botón de la interfaz de ArgoCD, la imagen anterior vuelve a estar activa en segundos, no en minutos. Tiempo típico: de 12 a 25 segundos. (2) Si hay una migración de base de datos, se requiere más cuidado: primero la migración inversa y después el rollback del contenedor. Por eso siempre diseñamos las migraciones para que sean retrocompatibles (patrón de dos pasos, como NULL allow → fill → NOT NULL). Regla de rollback automático: una infracción del SLO o un pico en la tasa de errores detiene automáticamente el despliegue progresivo de ArgoCD y, si es necesario, lo revierte. La intervención humana es opcional.
Deje de tenerles miedo a los lanzamientos.
En una reunión de 30 minutos evaluamos juntos su pipeline actual: dónde hay margen de mejora, qué pasos son críticos y cómo sería un plan concreto de 90 días.