Automação e feedback: Fechando o ciclo do DevOps
4 min ler

Em Capítulo 5: Ramificação e implantação contínuaexploramos como as ramificações de curta duração e uma plataforma de implantação contínua (CD) centralizada us ajudaram a acelerar a entrega e reduzir o atrito de integração. Essas mudanças melhoraram drasticamente o fluxo de código para a produção - mas para realmente completar o ciclo de feedback do DevOps, precisávamos de mais.

O Capítulo 6, o segmento final da nossa série DevOps for the Win, mergulha no último mas vital pilar da nossa transformação: Automação e feedback. Se a implantação contínua us ajudou a lançar mais rapidamente, então a automação e o feedback us ajudaram a aprender mais rapidamente, us melhorar continuamente com confiança.

Porque é que a automatização e o feedback são importantes

Em qualquer transformação DevOps, a velocidade sem segurança é uma receita para o desastre. À medida que a nossa frequência de implementação aumentava, a necessidade de verificações automatizadas e de feedback em tempo real tornou-se crítica - não só para a garantia de qualidade, mas também para a capacitação da equipa e para a tomada de decisões.

A automatização e os sistemas de feedback proporcionam às equipas:

  • Deteção precoce de problemas antes de reach produção
  • Confiança nas alterações, através de uma validação repetível e fiável
  • Métricas esclarecedoras para compreender o estado do sistema e o impacto no utilizador

É a diferença entre voar às cegas e voar com um painel de instrumentos.

Depois de melhorar a velocidade de desenvolvimento, o nosso próximo objetivo era identificar os estrangulamentos no ciclo de feedback quando a equipa de desenvolvimento marcava o trabalho como "concluído". Aqui, a principal medida de fluxo era a rapidez com que o trabalho concluído podia ser implementado na produção.

O Lead Time for Change e a Deployment Frequency são métricas chave para medir a eficiência com que o trabalho passa pelo sistema. No nosso caso, o trabalho estava a acumular-se na fase de QA do sistema (SQA), criando um estrangulamento na prontidão da implementação.

O estrangulamento da QA do sistema

Na maioria dos domínios, incluindo o nosso, os requisitos regulamentares impõem uma série de actividades de validação para garantir a qualidade do software. Isto inclui:

  • Teste de integração
  • Testes ao nível do sistema
  • Testes não funcionais (por exemplo, verificação da rede, testes de desempenho)
  • Artefactos de validação → Relatórios de testes do sistema, IQ (Qualificação da instalação), OQ (Qualificação operacional) e PQ (Qualificação do desempenho)

Estas tarefas devem ser efectuadas em ambientes controlados, separados do desenvolvimento, para garantir a conformidade. Por este motivo, a equipa QA do sistema funciona de forma independente e os testes só podem começar depois de a equipa de desenvolvimento concluir o seu trabalho.

Os nossos painéis de controlo mostraram que o tempo necessário para passar o trabalho concluído para o estado de pronto para produção estava a aumentar, com mais trabalho à espera que o SQA começasse a testar. Seguindo a nossa abordagem fundamental para melhorar o fluxo, esta era uma questão que tínhamos de resolver antes que quaisquer outras optimizações DevOps pudessem mostrar um valor real.

Principais desafios no fluxo do desenvolvimento para o SQA

Havia dois grandes desafios para melhorar o fluxo de trabalho do desenvolvimento para a QA do sistema:

  1. O atraso no início das tarefas de SQA
  2. A velocidade a que a validação do sistema pode ser executada

Se os testes de SQA forem essencialmente manuais, só podem começar quando o código estiver totalmente desenvolvido e implementado em ambientes controlados. Isto determina quando os testes podem começar e quanto tempo demoram a ser concluídos. O melhor que o SQA pode fazer neste modelo é preparar scripts de teste com antecedência, aguardando que a Definição de Conclusão (DoD) da equipa de desenvolvimento seja alcançada antes de executar os testes.

Automatização de SQA: Uma mudança na estratégia de testes

A única maneira de melhorar esse fluxo é concentrar-se maciçamente na automação. No entanto, não se trata apenas de automatizar a execução de testes - é necessária uma mudança fundamental na forma como os testes são abordados. Isso inclui:

  • Redefinição e realinhamento dos objectivos da QA do sistema.
  • Reavaliar a forma como a validação é efectuada para cumprir os requisitos regulamentares e de velocidade.
  • Reimaginar as ferramentas e as estruturas necessárias para apoiar eficazmente a automatização.

Uma das principais mudanças de mentalidade foi a passagem do teste para confirmar que o software desenvolvido está a funcionar → para o teste para orientar o desenvolvimento.

Isto significava criar scripts de teste, automatizá-los e executá-los num ambiente onde o código de desenvolvimento é regularmente enviado, mesmo antes de se atingir o DoD da funcionalidade. Aqui, as falhas nos testes não indicam um defeito, mas fornecem uma visão antecipada das partes da funcionalidade que ainda não estão implementadas ou totalmente funcionais.

Com pipelines de entrega contínua e uma estratégia de ramificação refinada em vigor, onde as ramificações de recursos são mescladas frequentemente na ramificação principal e implantadas na nuvem, configuramos um ambiente dedicado onde esses testes de sistema automatizados podem ser executados continuamente.

Feedback mais rápido com testes automatizados

Esta abordagem permitiu que a garantia de QA do sistema iniciasse a validação mais cedo, tornando os testes mais rápidos e fornecendo um feedback mais rápido à equipa de desenvolvimento. Em vez de esperar até que uma caraterística seja marcada como concluída, os testes decorrem agora em paralelo com o desenvolvimento, dando às equipas informações em tempo real sobre o que está a funcionar e o que ainda precisa de ser concluído.

Ao mesmo tempo, a automatização dos casos de teste exigiu que se repensassem as estratégias de teste.

  • Afastarmo-nos da automatização baseada na IU → os testes de API tornaram-se a prioridade.
  • Mudança para o desenvolvimento orientado para o comportamento (BDD) → Criação de guiões de teste juntamente com histórias de utilizadores a incluir nos critérios de aceitação.

Embora a adoção total do BDD desde o início da criação da história do utilizador seja ainda um trabalho em curso, melhorámos a colaboração entre as equipas de SQA e de desenvolvimento, alinhando-as desde o início do processo.

Alinhamento do SQA com o Desenvolvimento: A influência das topologias de equipa

Para o conseguir, aplicámos a abordagem de equipa especializada da Team Topologies, criando a equipa de SQA como uma equipa capacitadora. Em vez de ser uma função de teste separada e a jusante, os membros da equipa de SQA foram alinhados de perto com o desenvolvimento para garantir que a criação de casos de teste de automação começa cedo e funciona continuamente à medida que o código é desenvolvido.

Um pré-requisito fundamental para essa abordagem é ter um ambiente de teste cloud-based para executar testes no nível do sistema antes de passar para ambientes controlados. Embora isso introduza custos adicionais de infraestrutura, aumenta significativamente o fluxo de trabalho do desenvolvimento para o SQA, tornando-o pronto para implantação muito mais rápido.

Conclusão

Esta melhoria reforça um princípio central do DevOps - abordar a transformação tendo em conta as competências de Ferramentas, Arquitetura e Pessoas, concentrando-se simultaneamente no fluxo. Ao automatizar a garantia QA do sistema, integrando os testes no início do ciclo e alinhando as equipas de forma mais eficaz, reduzimos significativamente o estrangulamento entre o desenvolvimento e a validação do sistema, acelerando os ciclos de feedback e tornando as implementações mais fáceis.

Conclusão da série

Ao encerrarmos nossa série DevOps for the Win, refletimos sobre a jornada do caos de ferramentas e processos manuais para uma organização mais conectada, automatizada e capacitada. Desde a definição do nosso Triângulo DevOps no Capítulo 1 até ao estabelecimento da aprendizagem orientada por feedback no Capítulo 6, cada capítulo foi construído com base no anterior para conduzir a uma transformação significativa.

Aqui está uma breve recapitulação da nossa série:

Esta transformação está em curso - mas com a base que construímos, estamos mais bem equipados do que nunca para fornecer valor de forma mais rápida, mais segura e mais inteligente.

Obrigado por nos acompanhar nesta viagem. Esperamos que a nossa história inspire a sua própria evolução DevOps.

Mantenha-se curioso. Mantenham-se iterativos. E, mais importante, mantenha-se ligado.

Subscrever o Blogue Freyr