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


19

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)?

Respostas:


10

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.


Essa resposta é uma variação do que eu estou acostumado (mainframes), onde fazemos esse tipo de coisa há pelo menos 1,5 década ou mais (antes do "DevOps" nascer). Gostaria de saber se faria sentido adicionar minha própria resposta aqui (para expandir ainda mais essa resposta, como fazemos isso com o CMN / ZMF para, por exemplo, "bancos"), ou apenas levá-la a uma nova pergunta (auto-respondida). O que você acha? Além disso, estou curioso sobre essa coisa de metaphore, vale uma nova pergunta (com referência a esta resposta)? PS: você se importa se eu corrigir alguns erros de digitação?
Pierre.Vriens

Não há problema para editar :) Eu o mantive genérico, isso não é muito específico para um IMHO de devops org. Novamente, o DevOps é uma mudança na organização, que pode ajudar a configurar uma automação melhor, compartilhando as preocupações ... então eu chamo isso de semáforo, como na programação, acho que não vale a pena fazer uma pergunta, mas isso é com você
Tensibai

Ok, edite concluída (como de costume: retroceda / melhore como achar melhor). BTW, você tem um "s" no teclado?!?!?! Além disso: coisas para pensar no fim de semana: veja minha mais nova meta questão ... Bon weekend! Hora de jardinagem aqui (poda ...)
Pierre.Vriens

8

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.


Há muito o que digerir na sua resposta (não tenho certeza se já a obtive completamente). Mas o que você escreveu sobre " executar esse teste fora do seu processo de qualificação de CI / CD ": eu esperaria que o resultado final do que é produzido / entregue seja armazenado em seus ambientes de controle de qualidade e produtos (via CD, automático ou manual). Mas isso também " parece " para mim que o IC também deve entregar sua saída por lá, enquanto "fora" parece separação ou duplicação ou algo assim, não?
Pierre.Vriens

As referências insidee outsidesão relativas ao loop de verificação do IC. Basicamente, questiono o motivo da existência do ambiente de controle de qualidade - a maioria dos testes realizados lá deve ser confiável e, eventualmente, executada como parte das verificações de IC, especialmente em um contexto de implantação contínua - já que você deseja executá-los em todas as iterações de IC até esse ponto, pelo menos) de qualquer maneira.
Dan Cornilescu 14/03

7

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 :)?


ok, isso deve ajudar a melhorar a estabilidade, merci! Minha pergunta é sobre ambientes de "teste", portanto, obviamente, "produção" não deve ser considerada como tal. Apesar de quem usa "produção" para teste, você sabe o ditado " O melhor teste é ativá-lo na produção e, se não funcionar, basta executar uma reversão / retirada! "?
Pierre.Vriens

@ Pierre.Vriens, "tocando" no IMHO prod não é sábio :) Essa separação do ambiente é intencional. No trabalho anterior, tínhamos 5 ambientes diferentes ... Um voto útil
Romeo Ninov

1
"Eu" concordo que esse jogo não é sábio. No entanto, o que "você" pode fazer com os cowboys (meu 'termo' que eu uso para esses juppies) que continuam fazendo isso repetidamente, e sempre que obtêm aprovação de seus gerentes para contornar a (por exemplo) ativação da liberação mensal , por mais uma correção de bug (por exemplo, pela correção do bug do dia anterior ... que introduziu um novo bug). Você acha que isso não acontece no mundo real? BTW: sobre o "congelamento" em sua resposta, você acha que faz sentido postar uma pergunta como "O que são implementações de amostra de um ambiente congelado?"
Pierre.Vriens

@ Pierre.Vriens, para mim, faz todo sentido postar essa pergunta. Normalmente, esta é regulada por regras da empresa, mas DevOps criar um ambiente bastante dinâmico e isso pode re um verdadeiro desafio :)
Romeo Ninov

1
Esta é a minha abordagem preferida, de que maneira ele dá um ambiente onde os devs pode testar imediatamente as suas alterações em um ambiente integrado, mas mantém QA limpo até que o código está pronto para ser formalmente testada
Taegost

3

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.


3

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.


Pontos de vista / adições interessantes, embora existam algumas coisas que talvez você queira refinar / retrabalhar: (1) "aplicações" nesse contexto, o que você quer dizer (alguns exemplos?) (2) alguma idéia de como isso poderia funcionar? (bom e velho) ambientes de mainframe (3) o que é um "mitigante" neste contexto aqui? PS: deixe-me saber se você acha que eu deveria criar uma nova pergunta para qualquer uma dessas "coisas" (marcadores).
Pierre.Vriens
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.