Tu pipeline no debería ser solo build-test-deploy. Comparto cómo implementamos CI/CD avanzado en los proyectos de Previred.
El pipeline básico no es suficiente
La mayoría de equipos tienen: commit → build → test → deploy. Esto está bien para desarrollo, pero en producción necesitas más. Un deploy directo a producción sin red de seguridad es una receta para incidentes a las 3am.
Canary releases en Kubernetes
En SAGCOM 2.0, cada deploy a producción es un canary release. Primero se despliega al 5% del tráfico. Monitoreamos error rate, latencia p99 y métricas de negocio durante 15 minutos. Si todo está bien, se escala progresivamente: 5% → 25% → 50% → 100%. Si las métricas se degradan, rollback automático.
Feature flags
Desacoplamos deploy de release. Un feature puede estar deployado en producción pero deshabilitado detrás de un flag. Esto permite: hacer merge a main sin miedo, testear en producción con un grupo controlado, y activar features en el momento de negocio correcto (no cuando el deploy está listo).
Testing post-deploy
Después de cada deploy, una suite de smoke tests verifica los flujos críticos: login, consulta de evaluaciones médicas, creación de expedientes. Si alguno falla, se dispara rollback automático y alerta al equipo.
Observabilidad como prerequisito
Nada de esto funciona sin observabilidad. Usamos: Prometheus + Grafana para métricas, distributed tracing con OpenTelemetry, y logs estructurados. La regla: si no puedes medir el impacto de un cambio, no deberías deployarlo a producción.
