Padrões e anti-padrões de CI / CD. Parte 2

Boa tarde Hoje, estamos compartilhando com você a tradução da segunda parte do artigo “Padrões e antipadrões de CI / CD” , dedicado ao lançamento de um novo fluxo no curso “Práticas e ferramentas do DevOps” . A primeira parte deste artigo pode ser lida aqui .

1.3 Padrões e antipadrões nos testes

1.3.1 Automação de teste

• Padrão: automatize a validação e validação de software, incluindo unidades de teste, componentes, capacidade, funcionalidade e implantação.
• Antipadrões: teste manual de unidades, componentes, implantação, etc.
• Unidade - Automação de testes sem dependências.
• Componente - Automação de testes com dependências em outros componentes, bancos de dados e sistemas de arquivos.
• Implantação - Automatize testes para verificar a implantação e configuração bem-sucedidas. Isso às vezes é chamado de teste de "fumaça".
• Funcional - Automação de testes para verificar o comportamento do software do ponto de vista do usuário.
• Capacidade - Automação de carga e teste de desempenho em condições próximas à operacional.

1.3.2 Isolamento dos dados de teste

• Padrão: use transações para testes dependentes do banco de dados (por exemplo, teste de componentes) e reverta as transações quando concluídas. Use um pequeno subconjunto de dados para testar o comportamento de maneira eficaz.
• Antipadrões: usando uma cópia dos dados de produção para testes do Commit Stage. Executando testes em um banco de dados comum.

1.3.3 Testes paralelos

• Padrão: paralelamente, execute vários testes em instâncias de hardware para reduzir o tempo gasto.
• Antipadrões: executando testes em uma única máquina ou instância. Executando testes dependentes que não podem ser executados em paralelo.

1.3.4 Estabilidade do sistema

• Padrão: use stubs para simular sistemas externos e reduzir a complexidade da implantação.
• Antipadrões: instalação e configuração manual de sistemas interdependentes para construção e implantação do Commit Stage.

1.3.5 Teste de ponta a ponta considerado prejudicial

Entrega Contínua é um conjunto de princípios e práticas holísticas que visam reduzir o tempo de colocação no mercado. É baseado em feedback rápido e confiável, graças a testes. A Entrega Contínua exige que quaisquer alterações no código, configuração, dados ou infraestrutura sejam submetidas a um conjunto de testes exploratórios e automatizados no Deployment Pipeline para avaliar a prontidão operacional. Portanto, se a organização deseja atingir prazos mais curtos, o tempo de execução do teste deve ser baixo e os resultados do teste inequívocos.

Por exemplo, considere o serviço de Pagamentos da empresa, no qual os pagamentos no final do ano são enviados para o serviço de pagamentos subsequente.

O comportamento do serviço de pagamento da empresa pode ser verificado durante o tempo de montagem, executando os seguintes tipos de testes automáticos:

• Testes de unidade: comparando o objetivo e a implementação ao verificar os módulos de código individuais.
• Testes de aceitação: comparação de implementação e requisitos ao verificar a parte funcional do sistema.
• Testes de ponta a ponta: comparação da implementação e requisitos ao verificar a parte funcional do sistema, incluindo serviços dependentes sem dono.

Enquanto os testes de unidade e aceitação diferem em finalidade e escopo, os testes de aceitação e de ponta a ponta diferem apenas em volume. Os testes de aceitação não incluem serviços dependentes de órfãos; portanto, o teste de aceitação da viagem do usuário dos Pagamentos da empresa usará o Sistema de teste , que consiste no código da versão mais recente dos Pagamentos da empresa e no Stub of Payments.

Os testes de ponta a ponta incluem serviços dependentes sem dono; portanto, o teste de viagem de ponta a ponta do usuário dos Pagamentos da empresa usará o Sistema de teste que consiste no código mais recente dos Pagamentos da empresa e na versão de trabalho dos Pagamentos.

Se a estratégia de teste for compatível com a Entrega Contínua, ela deverá ter uma proporção apropriada de unidade, aceitação e testes de ponta a ponta que equilibram a necessidade de informações e feedback rápido e inequívoco. Se o teste não traz novas informações, os defeitos passam despercebidos. Mas se o teste demorar muito, a entrega será lenta e a receita perdida aumentará.

O fim da segunda parte.

De acordo com a tradição estabelecida, aguardamos seus comentários e convidamos você para um dia aberto . A terceira parte do artigo já está disponível aqui .