Hoje estamos observando como o modelo de desenvolvimento em cascata está morrendo gradualmente em todo o mundo. Ela não é amada por seu peso e pouca reação à mudança. Isso afeta diretamente a relevância do produto e aumenta o TTM (time-to-market), resultando em custos adicionais. Os desenvolvedores estão reconstruindo em trilhos ágeis, e não somos exceção.
A metodologia ágil foi criada originalmente para pequenas equipes que fabricam um produto chave na mão no modo ponta a ponta e são responsáveis por sua qualidade. Mas e se você desenvolver sistemas bancários altamente críticos sobre os quais dezenas de equipes ágeis trabalham? Como obter a confiança no produto que oferece um teste longo e abrangente como em cascata? Neste post, compartilharemos nossa solução para esse problema.
Todo mundo resolve o problema de maneiras diferentes, mas geralmente tudo se resume a testar a automação. Estão sendo desenvolvidos testes em stubs, regras gerais para formação de pedidos em atraso de equipes vizinhas são estruturas para interação entre equipes, como o SAFe. Como resultado, devido à sincronização da lista de pendências, as equipes de produtos relacionados podem gravar e realizar testes juntos, incluindo testes de integração. Nós temos tais estruturas.
Mas agora nos colocamos no lugar do proprietário de um sistema bancário complexo e altamente crítico. Afinal, quem é responsável pela qualidade de todo esse produto se estiver diretamente envolvido em dezenas de equipes ágeis responsáveis? Você precisa ter certeza de que nada falhará na produção. Introduzir testes adicionais? Oi, cachoeira e tchau, TTM.
Não existe uma solução perfeita. Nesta situação, sempre teremos um conflito entre os princípios da metodologia e a confiabilidade garantida do resultado. Este é o compromisso que encontramos.
Portões de qualidade
Se a especificidade do seu produto pressupuser que ele não está completamente isolado dos outros, nos pontos de contato você deve seguir uma regra - observe um nível mínimo de qualidade. O código deve ser coberto por testes de unidade, não deve conter defeitos críticos de segurança das informações, as distribuições devem passar por testes de fumaça à medida que são entregues. Sem lata, mas os requisitos são obrigatórios para todos. Sua implementação é uma passagem para testes gerais.
Portanto, em geral, a prática do
Quality Gates parece um conjunto de verificações automatizadas incorporadas ao pipeline de devops de cada sistema. De fato, ele reflete a tendência ao teste turno-turno, que agora é frequentemente discutido na estrutura de devops.
Concordamos com todas as equipes em uma série de verificações, portões de qualidade, pelas quais elas devem passar durante a passagem das etapas do ciclo de vida.
Codificação
Antes de criar o código, você precisa de uma análise estática obrigatória, verificando se o código está em conformidade com os padrões de uma linguagem de programação específica. Bem como a abrangência da cobertura com testes de unidade. Existem diferentes ferramentas para isso. Por exemplo, amamos o SonarQube. Depois de passar por esse portão de qualidade, as equipes podem ter certeza de que não violaram várias regras básicas desde o início. Por exemplo, duplicação significativa foi evitada, o que aumenta a complexidade do código e a probabilidade de problemas.
O segundo teste antes da montagem é uma verificação IS. Geralmente, existem práticas aceitas para identificar problemas de IS no código e ferramentas que podem digitalizar o código e identificar lugares perigosos. Por exemplo, uma variável declarada incorretamente pode levar a problemas na produção. Aqui concordamos em não permitir que tudo o que pode ser revelado na fase de redação do código seja feito para pentests e verificações mais complexas.
Construção de distribuição
Ao montar o kit de distribuição, sempre verificamos o resultado: se a montagem ocorreu corretamente, que todos os serviços foram iniciados e funcionam como deveriam, que o kit de distribuição pode ser instalado no ambiente desejado e funcionará. Esse teste de verificação interna elimina possíveis mal-entendidos entre o testador e o desenvolvedor. Na prática em cascata, o desenvolvedor terminou o trabalho, passou a distribuição aos testadores e, quando instalado no estande, descobriu-se que a montagem nem sequer começou. Então todo o ciclo foi interrompido, o desenvolvimento esticado e nada de bom aconteceu.
Nossa interação de integração é muito complicada. É importante não quebrar a posição em que outras equipes podem ser verificadas. Podemos fazer isso por causa de uma má distribuição, e os vizinhos do estande saberão disso antes de nós - simplesmente interromperemos todo o processo de trabalho para eles. Além disso, isso pode arruinar os dados do teste. E sua preparação também custa dinheiro e leva um tempo considerável. Especialmente quando se trata de dados anônimos do usuário.
Testes de fumaça
Como o kit de distribuição é instalado em cada banco de testes, ele passa por uma série de testes simples de fumaça. No banco de testes do sistema, a funcionalidade da distribuição é testada. Além disso, o kit de distribuição é colocado no suporte de teste de integração, onde as interações de integração são testadas. Também executa um conjunto de testes de fumaça. Se a distribuição não os passar, ele não poderá avançar para o próximo estágio.
Usando esses portões de qualidade, obtemos uma idéia inicial da qualidade da distribuição. Se os testes de fumaça foram bem-sucedidos, a equipe começa a testar. Se o kit de distribuição não passou nos testes de fumaça nesse estágio, provavelmente não passará no teste manual. Aqui, nós o atribuímos apenas se a montagem estiver potencialmente pronta para ir ao baile.
Portões de qualidade como estrutura
Nós nos esforçamos para garantir que os portões de qualidade se tornem uma estrutura completa para gerenciar a qualidade do desenvolvimento de um grande número de produtos em agile. Se uma equipe constantemente falha em passar por portas de qualidade obrigatórias, isso é um sinal de que há problemas que precisam ser discutidos e resolvidos. Por outro lado, se alguma equipe já dominou os portões básicos da qualidade e os incorporou a procedimentos internos, pode ir além e incluir portões adicionais da qualidade.
No futuro, planejamos lançar novos conjuntos de portões de qualidade obrigatórios. E também opcional, para que cada equipe com um nível suficiente de maturidade possa escolher o que precisa. Por exemplo, se você deseja determinar a estabilidade do pacote de distribuição nos locais de teste de integração, a equipe adotará portas de qualidade sozinhas. Se você precisar garantir que um conjunto complexo e com vários componentes não impeça a implantação, outros o farão. Alguém tem um viés em relação à segurança na frente, alguém em relação a testes de carga, disponibilidade de stands, resposta, alguém à frente da integração ou verificação de alguns dados. Cada equipe poderá encontrar portões de qualidade para o seu caso.
É importante observar que os portões de qualidade não substituem os testes, mas
uma ferramenta de controle principal . Ninguém cancela o teste. A principal tarefa aqui é minimizar os danos a outras equipes devido à baixa qualidade do produto o mais cedo possível.
Um exemplo de um pipeline de terceiros que inclui portões de qualidadeResultados da implementação de portões de qualidade
Primeiro de tudo, aumentamos a estabilidade do ciclo de produção. Uma mudança de ação, podemos detectar imediatamente erros críticos de funcionalidade. Menos tempo é gasto em várias iterações de teste; defeitos anteriores são detectados, portanto, sua eliminação é mais barata.
O lead time diminuiu - o tempo desde o início da codificação do recurso até sua implementação na produção. A estabilidade da fase de engenharia da TTM aumentou devido ao fato de termos reduzido o tempo de inatividade no processo de entrega do kit de distribuição ao ambiente industrial. Passamos o mesmo tempo para testes, mas não temos tempo de inatividade devido ao colapso do estande e à necessidade de aguardar a reconstrução da distribuição.
O tempo disponível para ambientes de teste aumentou. Antes, você poderia montar uma montagem e esquecê-la por uma semana. Enquanto isso, as equipes relacionadas não puderam ser testadas nesse ambiente, porque sua compilação está com defeito e você só saberá depois de uma semana. Agora, quando você coloca a montagem no chão, você mesmo a testa os problemas mais comuns, se necessário, reverte, finalize e devolva. E a chance de não parar ninguém se torna muito maior. A introdução de portões de qualidade também levará a uma redução no custo de restauração de estandes e reciclagem de dados de testes.
Sua opinião
Como dissemos no início, a contradição entre os princípios do desenvolvimento ágil e integrado não pode ser cortada como um nó górdio. Só podemos nos esforçar para garantir que isso traga o menor número possível de problemas. No nosso caso, a prática de portões de qualidade ajuda, mas, é claro, não o consideramos ideal. Como você resolve esse problema? Seria muito interessante discutirmos esse assunto.
Nikolay Vorobyov-Sarmatov, Sberbank-Technology, Sberworks
Agradecimentos a Mikhail Bizhan pela ajuda na preparação do artigo!