Qual é o objetivo da encenação?

18

Pensei ter trabalhado nisso, mas depois de ler Entrega contínua (excelente livro) um pouco confuso. Eles falam sobre ter servidores para:

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

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

    
por Hamish Downer 28.04.2011 / 19:02

4 respostas

13

O teste seria colocar os sistemas completos do produto no lugar, mas ainda não os está usando. Quando eles entram em uso seria "produção". Você deve colocar tudo no lugar como ele será usado, testar e, em seguida, apertar o botão.

O UAT geralmente usa ambientes de "teste" que são significativamente diferentes 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 nos nossos servidores. Quando o sistema entrar em operação, ele será executado em seu hardware, em suas instalações, provavelmente integrando-se a seus 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 de lá ...)

    
por 28.04.2011 / 19:13
17

Eu trabalho na equipe de gerenciamento de lançamentos em uma grande empresa de internet. Usamos essencialmente o processo que você descreveu acima e escolhemos esse processo propositalmente. Em nossa metodologia, o estadiamento serve como um mecanismo de ramificação para um nível final de teste na produção.

Obviamente, você quer fazer todos os testes antes de ir para 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, é virtualmente 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 muitos milhares de usuários atingindo seus servidores, as coisas falham em maneiras estranhas e difíceis de prever.

Então, aqui está o que fazemos:

  • Desenvolvimento
    • inclui integração contínua e testes automatizados
  • teste de lançamento
    • meu grupo analisa o lançamento em si
    • revisando os registros de instalação
    • teste de reversão
  • controle de qualidade
    • teste de aceitação do usuário

Esse é o ponto em que nos dividimos entre o teste e a produção. Nós usamos um modelo de trem para lançamentos, com um novo trem começando a cada poucas semanas. Até trens numerados vão para os servidores de teste (que estão em produção). Os trens numerados ímpares não.

Entre os trens pares, os desenvolvedores têm a capacidade de enviar alterações individuais para os servidores de teste ( após essas alterações foram testadas pelo controle de qualidade, é claro). Isso permite que eles validem que seu software funciona como esperado em um ambiente de produção real. Isto é geralmente reservado para os componentes que são considerados de alto risco, não empurramos cada pedacinho para a preparação.

Então, todo mundo entende que quando o próximo trem começa, ele vai acabar com o que está nos servidores de teste e os coloca de volta na linha de base do trem. Os desenvolvedores garantem que suas alterações entraram no trem ou decidiram que ainda não estão prontos para uso geral. Nesse caso, essas alterações são apagadas nos servidores de teste.

Para resumir, a resposta curta (pelo menos para nós) é que é impossível testar completamente sistemas complexos em QA. O estadiamento fornece uma maneira segura de realizar testes de produção limitados.

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

    
por 28.04.2011 / 19:59
5

A explicação mais simples para o teste é testar seu processo de implantação e testar usando a fonte de dados real. Alguns sistemas combinam o armazenamento temporário com seus ambientes de teste, mas, para sistemas de grande porte, o processo de implantação pode ser muito complexo ou podem ser necessárias etapas extras de teste quando você se conecta à fonte de dados ao vivo / de produção. Nesse caso, um ambiente de teste permite que você teste seu processo de implantação e verifique se há erros de última hora usando dados ativos e, depois que as coisas tiverem sido verificadas como funcionando, você poderá alternar rapidamente o ambiente de 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, realizar testes e, em seguida, troca instantaneamente os ambientes de produção e preparação .

    
por 28.04.2011 / 23:31
0

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

Staging is where you validate the known-unknowns of your systems.

O artigo vale muito a pena ler na íntegra.

    
por 23.10.2017 / 09:16