Serie CI/CD: Bonus y Buenas Prácticas

Las dos entregas anteriores cubrieron la configuración base y el trabajo cotidiano con pipelines. Acá cierro la serie con lo que los tutoriales suelen saltarse: gestión de secretos, seguridad real, cómo sobrevivir un rollback a las 3am, y optimizaciones que sí mueven la aguja.

Gestión de Secretos

Meter credenciales en el código o en variables de entorno sin cifrar es el error más común que veo en pipelines mal configurados. Claves API, contraseñas de bases de datos, tokens de terceros: todo eso necesita manejo explícito, no el enfoque de “después lo arreglamos”.

Herramientas de Gestión de Secretos

• Vault: La solución de HashiCorp. Más compleja de operar, pero la más flexible para entornos multi-nube o equipos grandes.
• AWS Secrets Manager: Si ya estás en AWS, es la opción obvia. Se integra bien con IAM y los servicios nativos.
• Kubernetes Secrets: Nativa del clúster. Ojo: los valores están codificados en base64, no cifrados. Sin configuración adicional, no es tan segura como parece.

# Ejemplo de uso de Kubernetes Secrets
apiVersion: v1
kind: Secret
metadata:
  name: mi-secreto
type: Opaque
data:
  usuario: YWRtaW4=  # "admin" en base64
  contraseña: MWYyZDFlMmU2N2Rm  # "1f2d1e2e67df" en base64

Seguridad en el Pipeline

La seguridad no es una etapa al final del pipeline. Es transversal a todo. Estas tres prácticas no son opcionales si el proyecto tiene algo de valor:

1. Escaneo de Vulnerabilidades: Una etapa dedicada a escanear el código fuente y las imágenes de contenedor antes de llegar a producción. Herramientas como Trivy o Snyk funcionan bien aquí.
2. Pruebas de Penetración: Periódicas, no después de un incidente. Muchos equipos las posponen hasta que ya es tarde, y esa decisión siempre sale cara.
3. Monitoreo de Logs: Los logs del pipeline son evidencia forense. Centralízalos y ponles alertas para patrones anómalos, no solo para fallos obvios.

Estrategias de Rollback

Los despliegues fallan. Con suficiente escala y frecuencia, es inevitable. La pregunta no es si va a pasar, sino qué tan rápido puedes recuperarte.

Despliegue Azul/Verde

Dos entornos de producción en paralelo. El tráfico apunta a uno mientras el otro recibe el nuevo despliegue. Si algo falla, cambiar el enrutamiento toma segundos. El costo es infraestructura duplicada, y en sistemas críticos ese gasto se justifica sin mucha discusión.

Canary Releases

Una fracción del tráfico real va a la nueva versión antes del rollout completo. Si las métricas se degradan o los errores suben, se revierte sin que la mayoría de usuarios lo note. Requiere instrumentación decente para que sea útil. Sin métricas confiables, los canaries son pura liturgia.

Backups y Restauración

Tener backups no alcanza. Lo que importa es cuánto tardas en restaurar y si el procedimiento funciona bajo presión real, no en condiciones de laboratorio. Prueba la restauración completa al menos una vez por trimestre. No alcanza con verificar que el backup existe.

Optimización del Pipeline

Paralelización de Tareas

Los pipelines lentos se abandonan. Cuando unit tests e integration tests corren en secuencia sin necesidad, estás pagando tiempo de espera sin ningún motivo técnico. Paralelizar las etapas independientes es el cambio con mejor ratio esfuerzo/impacto que conozco. Vale casi siempre.

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Construyendo la aplicación..."
    - make build

unit_test_job:
  stage: test
  script:
    - echo "Ejecutando pruebas unitarias..."
    - make unit_test

integration_test_job:
  stage: test
  script:
    - echo "Ejecutando pruebas de integración..."
    - make integration_test

Caché y Artefactos

Recompilar dependencias en cada corrida es puro desperdicio. El caché de node_modules o del repositorio local de Maven puede cortar minutos del pipeline sin tocar una línea de lógica de negocio.

cache:
  paths:
    - node_modules/
    - .m2/repository/

artifacts:
  paths:
    - target/

Automatización de Revisión de Código

Herramientas como SonarQube hacen análisis estático y detectan code smells, deuda técnica y vulnerabilidades conocidas antes del merge. No reemplazan la revisión humana. Lo que sí eliminan es el ruido de discusiones sobre estilo o errores mecánicos que un linter puede atrapar solo, y eso libera las revisiones para lo que realmente importa.

Documentación y Comunicación

Un pipeline que solo entiende quien lo escribió es un punto único de falla humano. La documentación no tiene que ser exhaustiva. Solo tiene que ser suficiente para que alguien que no estuvo en la reunión pueda operar el sistema a las 2am durante un incidente sin llamar a nadie. La comunicación entre equipos durante un despliegue no es burocracia: es la diferencia entre pisar un cambio ajeno y no pisarlo.