Quando a aceitação mente
Uma aplicação passa todos os testes em aceitação e falha em produção. Ao investigar aparece a diferença: outra versão do sistema operativo, outra configuração de rede, um serviço que em aceitação estava simulado e em produção não. A aceitação não estava a testar o que ia acontecer em produção; estava a testar outra coisa.
O que muda e o que não
Entre ambientes há diferenças legítimas e diferenças perigosas.
Podem variar, desde que estejam escritas:
- O tamanho (menos capacidade em desenvolvimento).
- Os dados (em aceitação, dados de teste ou anonimizados; nunca pessoais reais sem proteção).
- Os valores dos segredos (mesmos nomes, valores diferentes).
- Os endereços de publicação.
Nunca devem variar:
- O artefacto implementado (a mesma impressão digital, como vimos no artigo anterior).
- A plataforma de execução e as suas versões.
- O método de implementação.
- A forma da configuração: as mesmas chaves, ainda que mudem os valores.
Como se mantém
- A configuração por ambiente vive à parte do código e tem a mesma estrutura em todos.
- As diferenças estão num só lugar, geralmente o registo, e não espalhadas por scripts.
- Os ambientes criam-se com o mesmo código de infraestrutura, com parâmetros diferentes. Se um ambiente foi configurado à mão, tarde ou cedo será diferente dos restantes.
- Comparam-se periodicamente: uma revisão automática deteta o que se foi separando.
Com artefactos idênticos e ambientes comparáveis, falta a última proteção antes de publicar: validar tudo o que se possa verificar sem que ninguém tenha de olhar para isso.
Como o aplicamos: Engenharia de Plataforma.