Infraestrutura como Código promete o sonho: ambiente versionado, reproduzível, revisável. Na prática, muita base de Terraform vira o oposto: uma caixa-preta que só uma pessoa entende, com medo de rodar apply e um estado que ninguém ousa tocar. O problema raramente é a ferramenta; é a falta de estrutura para mais de uma mão trabalhar nela.
Estado é o coração: trate como tal
O state é a fonte da verdade do Terraform, e é onde quase todo desastre começa. Estado local no laptop de alguém é dívida garantida. O básico inegociável: backend remoto, com lock para evitar duas pessoas aplicando ao mesmo tempo, versionamento e acesso controlado. Sem isso, colaboração vira loteria.
Módulos com fronteira clara
Módulo bom não é o que abstrai tudo: é o que tem uma responsabilidade clara, entradas e saídas explícitas e documentação de como usar. Resista à tentação do "módulo que faz tudo": ele acopla o que deveria ser independente e vira justamente a peça que ninguém entende seis meses depois.
Se só uma pessoa pode rodar o apply com segurança, você não tem Infraestrutura como Código: tem um refém.
Separe ambientes de verdade
Dev, homologação e produção precisam de isolamento real de estado, não um único arquivo com if espalhado. Isolamento evita que um teste em dev encoste em produção e deixa cada ambiente com seu próprio raio de impacto. É o que permite experimentar sem prender a respiração.
Mudança de infra passa por revisão
- Plan no pull request: a revisão vê exatamente o que vai mudar antes de aprovar.
- Apply automatizado após merge, não no laptop de quem teve coragem.
- Padrões e nomenclatura versionados, para o código parecer escrito por uma pessoa só, mesmo escrito por dez.
- Lint e validação na esteira, pegando o erro barato antes que ele fique caro.
O inimigo silencioso: drift
Drift é quando alguém muda a infraestrutura na mão, fora do Terraform: um ajuste "rápido" no console, direto em produção. A partir daí o código mente sobre a realidade, e o próximo apply pode desfazer a correção ou quebrar outra coisa. Rodar plan com frequência (idealmente na esteira) expõe o drift cedo, enquanto ainda é fácil reconciliar. A regra cultural que sustenta tudo: mudança de infra acontece pelo código, nunca pelo console.
O objetivo é o ônibus, não o herói
O teste final de uma boa base de IaC é o "fator ônibus": se a pessoa que mais entende sair de férias, o time continua entregando com segurança? Estrutura, revisão e documentação existem para que a resposta seja sim. É disso que se trata autonomia.
Quando estruturamos IaC com um cliente, o entregável não é só o código: é o time saindo capaz de evoluir a infraestrutura sem depender de ninguém em específico, nem da gente. Se o seu Terraform virou caixa-preta, vamos conversar.