Como evitar instabilidades causadas por integração contínua em ambientes de teste?

Suponha que você esteja usando processos de integração contínua que atualizam frequentemente alguns ambientes de destino, para que toda vez que houver algumas alterações, "você" possa testar suas alterações imediatamente. Isso faz parte dos objetivos da CI, não?

Mas suponha também que você tenha outras pessoas envolvidas no seu ciclo de teste, por exemplo, gerentes ou clientes. Faz sentido envolver outras pessoas na tentativa de revisar (interromper?) Suas próximas alterações, não?

Porém, se você continuar continuamente entregando alterações no ambiente em que essas outras pessoas estão tentando seriamente testá-las, vários problemas poderão surgir, como:

• they pode perder tempo relatando problemas que, quando salvam o relatório (em profundidade), não podem mais reproduzir o problema (por exemplo, porque acidentalmente você também encontrou o mesmo problema e já o corrigiu no ambiente).
• you talvez não seja possível reproduzir os problemas relatados, pois os ambientes nos quais ocorreram alguns problemas não são mais idênticos (você (!!!) pode ter sobreposto o ambiente).

Então, o que você pode fazer (como configurar as coisas?) Para evitar situações (frustrantes)?

Darei minha experiência sobre este, principalmente porque mostra por que algumas respostas nem sempre são aplicáveis.

Algum contexto para começar:

• Temos 7 ambientes para hospedar aproximadamente 80 aplicativos, a maioria deles depende uns dos outros por meio de serviços da web ou tabelas compartilhadas no db2-iSeries.
• Para o bem ou para o mal, o iSeries é o nosso sistema de referência DB.
• Esse último ponto invalida qualquer idéia de trazer o aplicativo com suas dependências em um ambiente isolado, pois a instalação de um AS400 para cada um custaria muito e não teríamos o hardware para executá-lo de qualquer maneira.

O que estamos fazendo não é uma Entrega contínua automatizada completa, temos um cronograma de lançamentos para apresentar um monte coerente de aplicativos para as operações gerais. Além disso, cada equipe de teste pode acionar uma liberação em um ambiente de perguntas e respostas para o aplicativo que está testando e pode bloquear uma versão de aplicativo para evitar que outra solicitação de equipe interrompa seus testes.

As dependências dos aplicativos são verificadas antes do lançamento, para que o sistema não libere algo se outros aplicativos não puderem ser atualizados ou não corresponderem às dependências necessárias. A idéia principal é permitir atualizações quando isso não impactar alguém; se não houver testes planejados, deve fluir do ambiente anterior (e pretendemos remover as liberações agendadas nos 5 primeiros ambientes a médio prazo, agora temos validou este sistema de método 'on demand').

A versão curta é ter um sistema de 'semáforo' em torno dos aplicativos no ambiente; uma equipe deve poder bloquear seu aplicativo de destino com suas dependências (e dependências transitivas) para o tempo dos testes manuais.
A implementação deste semáforo é altamente dependente do seu sistema de automação, portanto não estenderei isso.

Obviamente, a maneira mais fácil é, como já mencionado, criar um ambiente novo para um aplicativo com todas as suas dependências, para evitar o semáforo descrito acima.

Parece que você está falando de um ambiente de teste que é constantemente reutilizado sem ser reinicializado de maneira confiável para cada execução de teste. Isso torna esse teste não confiável. Semelhante, da perspectiva da confiabilidade, com testes manuais, se você desejar.

IMHO, você não deve usar esses testes em seus propósitos de qualificação de CI / CD, pois isso invalidará efetivamente seu processo de qualificação (pelo menos nessa área). Dizer que o software passa no teste X sem realmente executar o teste X para todas as versões de software entregues ou sem ter a certeza de que o passresultado obtido não é acidental (devido a falsos positivos) corroerá o nível de confiança de seus testes. Os falsos negativos não são prejudiciais à credibilidade, mas também são indesejados por causa do "ruído" desnecessário que eles criam.

Não há problema em executar esses testes fora do processo de qualificação de CI / CD. Mas você estaria tratando um resultado com falha em tais testes, como um bug encontrado pelo cliente: seria necessário reproduzir o problema de forma confiável para poder desenvolver uma correção e confirmar se a correção está funcionando. E você realmente não pode fazer isso se o teste não for confiável.

Se você planeja resolver o problema, o ideal é desenvolver um caso de teste automatizado e confiável para reproduzir o problema. Que você usaria para desenvolver uma correção e confirmar sua eficácia (o resultado do teste deve passar de FAIL para PASS). Você também pode (deve?) Colocar esse testcase dentro do seu processo de qualificação de CI / CD para impedir a ocorrência futura, se desejado - para aumentar o nível geral de qualidade da versão do software.

A abordagem usual é criar ambientes diferentes:

DEV - este é o lugar onde a equipe de desenvolvimento mexe com as coisas. Aqui, crie todos os ajustes de alterações, implante uma nova versão e assim por diante. Aqui é o local em que o CI está totalmente integrado.

PREPROD / QA - este é o local em que a equipe de controle de qualidade / teste / validação realiza testes. Esse ambiente geralmente congela durante os testes. A integração do IC com esse ambiente é apenas para fornecer uma nova versão do produto, configurações, etc.

PRODUÇÃO - é preciso explicar :)?

Se você estiver executando um CI / CD, isso implica que existem alguns testes automatizados (CI) antes da implantação (CD). Se você encontrar muitos problemas em seu ambiente de teste, isso significa que eles não estão sendo detectados pelos testes executados antes da implantação; isso indica testes automatizados insuficientes. Se os desenvolvedores estão tendo problemas em que os defeitos estão surgindo no (s) ambiente (s) de teste, eles precisam melhorar seus conjuntos de testes automatizados para evitar isso. Isso também melhorará a qualidade e a confiabilidade em geral, até a produção.

Para adicionar à resposta de Romeo Ninov, internamente em um ambiente, você precisa tentar separar os aplicativos o máximo possível. Isso é parcialmente porque o docker foi tão bem-sucedido no desenvolvimento / teste. Vamos quase fingir que não estamos compartilhando um ambiente.

A outra opção é ter servidores bem definidos nos quais os aplicativos são executados, separados do restante da infraestrutura que compõe seu ambiente. Ou seja. Todo o mecanismo de gerenciamento ou ativação de ambiente funciona em servidores separados e de longa duração. Em seguida, você conecta novos servidores de curta duração com base em uma imagem conhecida para testar um aplicativo e, se alguma alteração for feita na imagem base, será necessário aplicar essas alterações em todos os lugares para cada novo componente. O que significa testar as alterações contra tudo.

Se uma equipe do appdev solicitar uma alteração que interrompa o aplicativo de outra pessoa, então, por sorte, eles precisam criar internamente um mitigante em seu código e manter seus requisitos específicos separados dos ambientes oferecidos.