Automação e feedback: Fechar o ciclo DevOps
4 min de leitura

Em Capítulo 5: Ramificação e Implementação Contínua, explorámos como as ramificações de curta duração e uma plataforma centralizada de implementação contínua (CD) nos ajudaram a acelerar a entrega e a reduzir a fricção de integração. Estas alterações melhoraram dramaticamente o fluxo de código para produção, mas para concluir verdadeiramente o ciclo de feedback de DevOps, precisávamos de mais.

Capítulo 6, o segmento final da nossa série DevOps for the Win, mergulha no último, mas vital, pilar da nossa transformação: Automatização e Feedback. Se a implementação contínua nos ajudou a lançar mais rapidamente, a automatização e o feedback ajudaram-nos a aprender mais depressa, permitindo-nos melhorar continuamente com confiança.

Porque é que a Automatização e o Feedback são Importantes

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

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

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

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

Após efetuar melhorias na velocidade de desenvolvimento, o nosso foco seguinte centrou-se na identificação de estrangulamentos no ciclo de feedback assim que 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 em produção.

O Tempo de Espera para Alteração e a Frequência de Implementação são métricas fundamentais para medir a eficiência com que o trabalho se desloca pelo sistema. No nosso caso, o trabalho estava a acumular-se na fase de QA do sistema (SQA), criando um estrangulamento na prontidão para implementação.

O Estrangulamento de QA do Sistema

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

  • Testes de Integração
  • Testes ao Nível do Sistema
  • Testes Não Funcionais (por exemplo, verificação de rede, testes de desempenho)
  • Artifacts de Validação → Relatórios de Testes do Sistema, IQ (Qualificação de Instalação), OQ (Qualificação Operacional) e PQ (Qualificação de Desempenho)

Estas tarefas devem ser executadas em ambientes controlados, separados do desenvolvimento, para garantir a conformidade. Por conseguinte, a equipa de QA do sistema opera de forma independente e os testes só podem começar após a conclusão do trabalho pela equipa de desenvolvimento.

Os nossos painéis de instrumentos mostravam que o tempo necessário para mover o trabalho concluído para o estado pronto para produção estava a aumentar, com mais trabalho à espera que o SQA iniciasse os testes. Seguindo a nossa abordagem fundamental para melhorar o fluxo, este era um problema que tínhamos de resolver antes que quaisquer outras otimizações de DevOps pudessem mostrar valor real.

Principais Desafios no Fluxo de Dev para SQA

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

  1. O atraso no início das tarefas de SQA
  2. A velocidade à qual a validação do sistema podia 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 tanto o momento em que os testes podem começar quanto o tempo necessário para os concluir. O melhor que a SQA pode fazer neste modelo é preparar os guiões de teste com antecedência, aguardando que a equipa de desenvolvimento atinja a Definição de Conclusão (DoD) antes de executar os testes.

Automatizar a SQA: uma mudança na estratégia de testes

A única forma de melhorar este fluxo é apostar fortemente na automação. No entanto, não se trata apenas de automatizar a execução de testes; exige uma mudança fundamental na forma como os testes são encarados. Isto inclui:

  • Redefinir e realinhar os objetivos da QA de sistemas.
  • Reavaliar a forma como a validação é efetuada para cumprir os requisitos de velocidade e regulamentação.
  • Reimaginar as ferramentas e os enquadramentos necessários para apoiar a automação de forma eficaz.

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

Isto significava criar, automatizar e executar guiões de teste num ambiente onde o código de desenvolvimento é enviado regularmente, mesmo antes de a funcionalidade atingir a DoD. Aqui, as falhas nos testes não indicam um defeito, mas sim uma perspetiva antecipada sobre que partes da funcionalidade ainda não foram implementadas ou não estão totalmente operacionais.

Com pipelines de entrega contínua e uma estratégia de ramificação refinada, onde as ramificações de funcionalidades são frequentemente fundidas na ramificação principal e implementadas na nuvem, criámos um ambiente dedicado onde estes testes de sistema automatizados podiam correr continuamente.

Feedback mais rápido com testes automatizados

Esta abordagem permitiu que a QA de sistemas iniciasse a validação mais cedo, tornando os testes mais rápidos e fornecendo um feedback mais célere à equipa de desenvolvimento. Em vez de esperar até que uma funcionalidade seja considerada concluída, os testes decorrem agora em paralelo com o desenvolvimento, oferecendo às equipas dados 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 repensar as estratégias de teste.

  • Afastar-se da automação baseada na interface do utilizador (UI) → os testes de API tornaram-se a prioridade.
  • Transição para o Desenvolvimento Orientado por Comportamento (BDD) → Criar guiões de teste juntamente com as histórias de utilizador para serem incluídos nos critérios de aceitação.

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

Alinhar a SQA com o desenvolvimento: a influência das topologias de equipa

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

Um pré-requisito fundamental para esta abordagem é dispor de um ambiente de teste cloud-based para executar testes ao nível do sistema antes de passar para ambientes controlados. Embora isto introduza custos de infraestrutura adicionais, aumenta significativamente o fluxo de trabalho do desenvolvimento para a SQA, tornando o processo pronto para implementação muito mais rapidamente.

Conclusão

Esta melhoria reforça um princípio central de DevOps: abordar a transformação tendo em conta as competências de Ferramentas, Arquitetura e Pessoas, focando-se no fluxo. Ao automatizar a QA de sistemas, integrar os testes mais cedo no ciclo e alinhar 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 fluidas.

Conclusão da série

Ao concluirmos a nossa série DevOps for the Win, refletimos sobre o percurso desde o caos de ferramentas e processos manuais até uma organização mais ligada, automatizada e capacitada. Desde a definição do nosso Triângulo DevOps no Capítulo 1 até ao estabelecimento de uma aprendizagem impulsionada pelo feedback no Capítulo 6, cada capítulo construiu sobre o anterior para impulsionar uma transformação significativa.

Eis um breve resumo da nossa série:

Esta transformação é contínua, mas com a base que construímos, estamos mais bem preparados do nunca para entregar valor de forma mais rápida, segura e inteligente.

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

Mantenha-se curioso. Mantenha-se iterativo. E, mais importante, mantenha-se conectado.

Subscrever o blogue da Freyr