6 min lectura • Guide 762 of 877
Gestión de Proyectos Infrastructure as Code
Infrastructure as Code (IaC) requiere el mismo rigor que el desarrollo de aplicaciones. GitScrum ayuda a los equipos a gestionar trabajo de infraestructura con procesos de review apropiados y tracking de cambios.
Estructura de Tareas de Infraestructura
Formato de Tareas IaC
ESTRUCTURA DE TAREA DE INFRAESTRUCTURA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREA DE CAMBIO DE INFRAESTRUCTURA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INFRA-100: Agregar cluster Redis para caching ││
│ │ ││
│ │ QUÉ: ││
│ │ Provisionar cluster ElastiCache Redis (3 nodos) ││
│ │ ││
│ │ POR QUÉ: ││
│ │ Capa de caching de aplicación para PROJ-456 ││
│ │ Soporta: Almacenamiento de sesión, cache de API ││
│ │ ││
│ │ RECURSOS: ││
│ │ • Cluster ElastiCache (cache.r6g.large x 3) ││
│ │ • Security group ││
│ │ • Parameter group ││
│ │ • Subnet group ││
│ │ ││
│ │ IMPACTO DE COSTO: ││
│ │ Estimado: ~$400/mes ││
│ │ Aprobado: Sí (ticket BUDGET-123) ││
│ │ ││
│ │ BLAST RADIUS: ││
│ │ Solo recursos nuevos - sin impacto a existentes ││
│ │ ││
│ │ ROLLBACK: ││
│ │ terraform destroy para nuevos recursos ││
│ │ ││
│ │ VENTANA DE DEPLOYMENT: ││
│ │ Cualquier momento (sin downtime esperado) ││
│ │ ││
│ │ CHECKLIST: ││
│ │ ☐ Código Terraform ││
│ │ ☐ Code review ││
│ │ ☐ Apply en staging ││
│ │ ☐ Probar conectividad ││
│ │ ☐ Apply en producción ││
│ │ ☐ Actualizar documentación ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Categorías de Cambios
TIPOS DE CAMBIOS DE INFRAESTRUCTURA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BAJO RIESGO (Auto-aprobación OK): │
│ • Recursos nuevos (sin impacto existente) │
│ • Cambios de tags │
│ • Aumentar capacidad │
│ • Agregar monitoreo │
│ │
│ RIESGO MEDIO (Peer review requerido): │
│ • Cambios de security group │
│ • Actualizaciones de IAM policy │
│ • Cambios de configuración │
│ • Políticas de scaling │
│ │
│ ALTO RIESGO (Múltiples reviewers + ventana): │
│ • Cambios de database │
│ • Cambios de red │
│ • Operaciones destructivas │
│ • Secrets de producción │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TAREA DE ALTO RIESGO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 INFRA-150: Migrar a nuevo VPC ││
│ │ ││
│ │ Riesgo: ALTO ││
│ │ Downtime: Esperado (ventana de mantenimiento) ││
│ │ ││
│ │ APROBACIÓN REQUERIDA: ││
│ │ ☐ Review de lead DevOps ││
│ │ ☐ Review de seguridad (cambio de red) ││
│ │ ☐ Change advisory board ││
│ │ ││
│ │ DEPLOYMENT: ││
│ │ ☐ Ventana programada: Sábado 2AM ││
│ │ ☐ Plan de rollback documentado ││
│ │ ☐ Equipo on-call notificado ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Flujo de Trabajo Terraform
Flujo de Tareas Terraform
FLUJO DE TRABAJO DE CAMBIOS TERRAFORM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. CREAR TAREA │
│ Documentar qué/por qué/impacto │
│ │
│ 2. DESARROLLAR │
│ Escribir código Terraform │
│ terraform plan localmente │
│ │
│ 3. CODE REVIEW │
│ PR con output de terraform plan │
│ Revisar cambios cuidadosamente │
│ │
│ 4. STAGING APPLY │
│ terraform apply en staging │
│ Verificar funcionalidad │
│ │
│ 5. PRODUCTION APPLY │
│ Programado si es de alto riesgo │
│ terraform apply en producción │
│ Verificar y monitorear │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CHECKLIST DE PR PARA TERRAFORM: │
│ │
│ ☐ terraform fmt aplicado │
│ ☐ terraform validate pasa │
│ ☐ Output de plan incluido en PR │
│ ☐ Sin secrets en código │
│ ☐ Estimación de costo incluida (para nuevos recursos) │
│ ☐ Documentación actualizada │
│ ☐ Plan de rollback documentado │
│ │
│ OUTPUT DE PLAN EN PR: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Plan: 3 to add, 1 to change, 0 to destroy. ││
│ │ ││
│ │ + aws_elasticache_cluster.main ││
│ │ + aws_security_group.redis ││
│ │ + aws_elasticache_subnet_group.main ││
│ │ ~ aws_security_group.app (add egress rule) ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Trabajo de Kubernetes
Estructura de Tareas K8s
TAREA DE CAMBIO DE KUBERNETES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CAMBIO DE DEPLOYMENT K8S: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INFRA-200: Actualizar configuración de deployment API ││
│ │ ││
│ │ CAMBIOS: ││
│ │ • Aumentar replicas: 3 → 5 ││
│ │ • Actualizar resource limits ││
│ │ • Agregar readiness probe ││
│ │ ││
│ │ MANIFEST AFECTADOS: ││
│ │ • deployments/api-server.yaml ││
│ │ • configmaps/api-config.yaml ││
│ │ ││
│ │ TESTING: ││
│ │ ☐ Apply en cluster dev ││
│ │ ☐ Verificar health checks ││
│ │ ☐ Load test con nuevos límites ││
│ │ ││
│ │ ROLLBACK: ││
│ │ kubectl rollout undo deployment/api-server ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ HERRAMIENTAS UTILIZADAS: │
│ • kubectl para aplicar cambios │
│ • Helm para gestión de charts │
│ • ArgoCD para GitOps │
│ • Lens/k9s para debugging │
│ │
└─────────────────────────────────────────────────────────────┘
Coordinación con Desarrollo
SINCRONIZACIÓN INFRA + APP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DEPENDENCIAS: │
│ │
│ INFRA-100: Cluster Redis ◄───── APP-456: Caching layer │
│ (debe completarse primero) (necesita Redis) │
│ │
│ PLANIFICACIÓN EN SPRINT: │
│ │
│ Día 1-3: INFRA-100 (provisionar Redis) │
│ └── DevOps completa e integra │
│ │
│ Día 4-8: APP-456 (implementar caching) │
│ └── Dev usa nuevo cluster │
│ │
│ COMUNICACIÓN: │
│ • INFRA-100 completada → Notificar equipo de app │
│ • Connection strings en documentation │
│ • Handoff documentado │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
- Documentar blast radius para cada cambio
- Plan de rollback siempre documentado
- Review requerido para cambios de riesgo medio+
- Staging primero antes de producción
- Ventanas de mantenimiento para alto riesgo
- Coordinar con desarrollo para dependencias