Versionar infraestructura no elimina el riesgo de cambiarla. Un pull request puede parecer pequeño y producir el reemplazo de una base de datos, abrir una regla de red o reducir la retención de copias. La revisión necesita ver el plan contra el estado real, no solo el texto modificado.
Terraform construye un plan comparando configuración, estado previo y recursos remotos. Su documentación muestra que algunas modificaciones aparecen como actualización y otras como eliminación y creación. Esa clasificación debe convertirse en una señal visible para quien aprueba.
Qué debe conservar un plan revisable
Genera el plan con versiones fijadas del CLI y de los proveedores, credenciales de solo lectura cuando sea posible y el mismo conjunto de variables que recibirá el entorno. Conserva como evidencia:
- commit de configuración;
- entorno y workspace;
- versiones de herramientas y módulos;
- resumen de altas, cambios, sustituciones y bajas;
- recursos sensibles afectados;
- instante de generación y resultado de políticas;
- huella del artefacto que se aplicará.
Si se aprueba un plan guardado, aplica ese artefacto. Regenerarlo después de la aprobación puede introducir otra decisión. Si el estado cambia entretanto, detén la aplicación y vuelve a revisar.
Clasifica por consecuencia
Un contador 0 add, 2 change, 0 destroy no explica el impacto. Añade reglas para destacar:
| Señal | Revisión requerida |
|---|---|
| Reemplazo de almacén con datos | migración, copia y prueba de restauración |
| Cambio de red o identidad | seguridad y alcance efectivo |
| Reducción de réplicas | capacidad y disponibilidad |
| Cambio de región | residencia, latencia y coste |
| Destrucción | propietario del servicio y plan de recuperación |
| Etiqueta o descripción | revisión ordinaria |
Los datos amplifican el riesgo: sustituir un nodo efímero y sustituir un bucket no tienen la misma consecuencia aunque ambos aparezcan como replace.
Detecta deriva sin corregirla a ciegas
La deriva ocurre cuando el recurso real cambia fuera del flujo de código. HashiCorp recomienda terraform plan -refresh-only para inspeccionar las diferencias entre estado y realidad. Ese modo no revierte los recursos; permite decidir si el cambio manual debe incorporarse a configuración o deshacerse mediante un plan normal.
No ejecutes un refresco que sobrescriba estado automáticamente como primera respuesta. Una credencial incorrecta o una API incompleta puede hacer que recursos existentes parezcan ausentes. Conserva la salida, identifica al propietario y decide:
- Aceptar: llevar la configuración al estado real y revisar el plan final.
- Revertir: aplicar la configuración aprobada para restaurar el recurso.
- Importar o corregir estado: cuando el recurso es válido pero no está representado correctamente.
Flujo de entrega recomendado
- valida formato, sintaxis y módulos;
- genera el plan en un entorno aislado;
- ejecuta políticas sobre seguridad, coste y destrucción;
- publica un resumen legible y el artefacto completo;
- exige aprobación proporcional al impacto;
- aplica exactamente el plan aprobado;
- ejecuta comprobaciones del servicio y guarda el resultado.
Separa credenciales y estado entre desarrollo, pruebas y producción. Una rama distinta no constituye aislamiento si todos los planes apuntan a la misma cuenta.
Criterios de aceptación
La entrega está controlada cuando el equipo puede responder qué cambiará, por qué, quién lo aprobó, qué comprobación confirma el resultado y cómo volver atrás. Programa además detección de deriva en recursos críticos y alerta sobre diferencias, sin autoaplicar correcciones destructivas.
La infraestructura como código aporta trazabilidad cuando configuración, plan, aprobación y resultado forman una cadena. Guardar solo el código deja fuera la parte más importante: la consecuencia real del cambio.