A tentação de copiar e colar
Já funciona o ambiente de desenvolvimento. Falta a aceitação: copia-se a pasta, mudam-se uns nomes e está feito. Depois a produção, outra cópia. Ao cabo de um ano há seis cópias que começaram iguais e já não o são. Alguém corrige uma falha de segurança numa e esquece-se das outras cinco.
É o mesmo problema que tem o código de uma aplicação quando se duplica, e a solução é a mesma: uma só definição que se reutiliza.
O que é um módulo
Um módulo é um bloco de infraestrutura com um propósito claro e poucos parâmetros. Por exemplo, «um serviço web com o seu balanceador, a sua base de dados e as suas regras de rede», onde os parâmetros são o tamanho, o número de instâncias e o nome do ambiente.
Cada ambiente usa o módulo com os seus valores; não o copia. Se o módulo for corrigido, a correção chega a todos os ambientes que o usam.
Como se desenha um bom módulo
| Bem | Mal |
|---|---|
| Um propósito que se explica numa frase | «Tudo o da aplicação X» |
| Poucos parâmetros, com valores por omissão seguros | Dezenas de parâmetros para cobrir cada caso |
| Seguro por omissão: cifra ativada, nada exposto | Insegura a não ser que se configure |
| Versionado: cada ambiente fixa que versão usa | Sempre a última, para todos ao mesmo tempo |
| Documentado com um exemplo de utilização | É preciso ler o código para o usar |
Versionar para mudar com calma
Que todos os ambientes usem a mesma definição não significa que mudem ao mesmo tempo. Cada ambiente declara que versão do módulo usa. Uma melhoria testa-se primeiro em desenvolvimento, depois em aceitação e por fim em produção, como qualquer outra mudança.
Reutilizar bem reduz erros. Mas cada mudança continua a ter risco, e antes de a aplicar há que ver exatamente o que vai fazer. Para isso existe o plano.
Como o aplicamos: Automação e IaC.