Qual é o sentido da preparação?

Eu pensei que tinha resolvido isso, mas depois de ler Entrega Contínua (livro excelente), estou um pouco confuso. Eles falam sobre ter servidores para:

• desenvolvimento
• várias formas de testes automatizados
• teste de aceitação do usuário (UAT) - ou seja, sentar-se com o cliente e demonstrá-lo a ele e deixá-lo fazer testes exploratórios. Os testadores internos também podem usar essa configuração para testes exploratórios.
• encenação
• Produção.

Eu sempre pensei em organizar como fornecendo a função UAT, mas eles parecem ter como um nível separado. Portanto, nesse esquema, que função os servidores de teste forneceriam?

A preparação seria a instalação de todos os sistemas de produtos, mas ainda não os será usado. Quando eles entram em uso seria "produção". Você deve colocar tudo no lugar que será usado, testar e depois pressionar o interruptor.

O UAT geralmente usa um ambiente de "teste" significativamente diferente do hardware / software / configuração que será usado na produção.

Por exemplo, onde trabalho, os clientes testam tudo em um ambiente de VM em execução em nossos servidores. Quando o sistema entra em operação, ele estará executando no hardware, nas instalações, provavelmente integrando-se aos sistemas existentes; não terá absolutamente nada a ver com nossos servidores ou ambiente de teste (exceto que o código e algumas configurações foram copiadas a partir daí ...)

Trabalho na equipe de gerenciamento de lançamentos de uma empresa de internet muito grande. Usamos essencialmente o processo descrito acima e escolhemos esse processo de propósito. Em nossa metodologia, a preparação serve como um mecanismo de ramificação para um nível final de teste na produção.

Obviamente, você deseja fazer todos os testes antes de iniciar a produção, mas em um ambiente grande e complexo com muitos usuários, esse é um objetivo muito difícil de alcançar. Em particular, é praticamente impossível carregar adequadamente o software de teste no controle de qualidade. O teste funcional é muito mais fácil de automatizar do que o teste de carga. Quando você tem milhares de usuários acessando seus servidores, as coisas falham de maneira estranha e difícil de prever.

Então, aqui está o que fazemos:

• Desenvolvimento
  • inclui integração contínua e testes automatizados
• teste de liberação
  • meu grupo analisa o lançamento em si
  • revendo logs de instalação
  • reversão de teste
• QA
  • Testes de aceitação do usuário

Esse é o ponto em que nos ramificamos entre preparação e produção. Usamos um modelo de trem para lançamentos, com um novo trem iniciando a cada poucas semanas. Até os trens numerados vão para os servidores intermediários (que estão em produção). Trens numerados ímpares não.

Entre os trens pares, os desenvolvedores têm a capacidade de enviar alterações individuais aos servidores de teste ( depois que essas alterações foram testadas pelo controle de qualidade, é claro). Isso permite que eles validem que seu software tenha o desempenho esperado em um ambiente de produção real. Geralmente, isso é reservado para os componentes que são considerados de maior risco; não levamos cada pedacinho para a preparação.

Então, todo mundo entende que, quando o próximo trem par for iniciado, ele eliminará o que está nos servidores de preparo e os colocará de volta na linha de base do trem. Os desenvolvedores garantem que as alterações entrem em ação ou decidem que ainda não estão prontos para uso geral. Nesse caso, essas alterações são apagadas nos servidores de teste.

Em resumo, a resposta curta (pelo menos para nós) é que é impossível testar completamente sistemas complexos no controle de qualidade. A preparação fornece uma maneira segura de realizar testes de produção limitados.

Em uma nota relacionada, aqui estão meus slides de uma apresentação que acabei de dar sobre como nosso processo de lançamento funciona.

A explicação mais simples para a preparação é testar seu processo de implantação e testar usando a fonte de dados real. Alguns sistemas combinam a preparação com seus ambientes de teste, mas, para sistemas de grande escala, o processo de implantação pode ser muito complexo ou podem ser etapas extras de teste necessárias depois que você se conecta à fonte de dados ao vivo / produção. Nesse caso, um ambiente de armazenamento temporário permite testar seu processo de implantação e verificar bugs de última hora usando dados dinâmicos e, depois que as coisas estiverem verificadas como funcionando, você poderá rapidamente mudar o ambiente do palco para o ambiente de produção.

Um exemplo disso seria o Windows Azure, que requer de 5 a 25 minutos para implantar uma nova versão, mas você pode implantar em um ambiente de preparação, executar testes e trocar instantaneamente os ambientes de produção e preparação .

Acabei de encontrar este artigo sobre ambientes de preparação que diz

A preparação é onde você valida as incógnitas conhecidas de seus sistemas.

Vale a pena ler o artigo na íntegra.