Automação e Feedback: Fechando 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 o atrito de integração. Estas alterações melhoraram drasticamente o fluxo de código para produção, mas para completar verdadeiramente o ciclo de feedback DevOps, precisávamos de mais.

Capítulo 6, o segmento final da nossa série DevOps para a Vitória, aborda o último, mas vital, pilar da nossa transformação: Automação e Feedback. Se a implementação contínua nos ajudou a lançar mais rapidamente, então a automação e o feedback nos ajudaram a aprender mais depressa, permitindo-nos melhorar continuamente com confiança.

A Importância da Automação e do Feedback

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 feedback em tempo real tornou-se crítica – não apenas para a garantia de qualidade, mas para o empoderamento da equipa e a tomada de decisões.

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

  • Deteção precoce de problemas antes que cheguem à produção
  • Confiança nas alterações, através de validação repetível e fiável
  • Métricas informativas 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 controlo.

Após melhorar a velocidade de desenvolvimento, o nosso próximo foco foi identificar os 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 Ciclo para a Mudança e a Frequência de Implementação são métricas chave para medir a eficiência com que o trabalho se move através do sistema. No nosso caso, o trabalho estava a acumular-se na fase de QA do sistema (SQA), criando um estrangulamento na prontidão para a implementação.

O Estrangulamento do 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 de Sistema
  • Testes Não Funcionais (por exemplo, verificação de rede, testes de desempenho)
  • Artefactos de Validação → Relatórios de Testes de Sistema, IQ (Qualificação de Instalação), OQ (Qualificação Operacional) e PQ (Qualificação de Desempenho)

Estas tarefas devem ser realizadas em ambientes controlados, separados do desenvolvimento, para garantir a conformidade. Devido a isto, a equipa de QA do sistema opera 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 mover o trabalho concluído para o estado de prontidão 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 otimizações DevOps adicionais pudessem demonstrar valor real.

Principais Desafios no Fluxo de Desenvolvimento para SQA

Havia dois grandes desafios na melhoria do fluxo de trabalho do desenvolvimento para o QA do sistema:

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

Se os testes de SQA são principalmente manuais, só podem começar depois de o código estar totalmente desenvolvido e implementado em ambientes controlados. Isto determina tanto quando os testes podem começar como quanto tempo levarão a ser concluídos. O melhor que o SQA pode fazer neste modelo é preparar os scripts de teste com antecedência, à espera que a Definição de Concluído (DoD) da equipa de desenvolvimento seja alcançada antes de executar os testes.

Automatizar o 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 abordados. Isto inclui:

  • Redefinir e reajustar os objetivos do QA do sistema.
  • Reavaliar a forma como a validação é realizada para cumprir os requisitos de velocidade e regulamentares.
  • Repensar as ferramentas e estruturas necessárias para apoiar a automação de forma eficaz.

Uma das principais mudanças de mentalidade foi passar de testes para confirmar que o software desenvolvido funciona → para testes que orientam o desenvolvimento.

Isto significou que os scripts de teste foram criados, automatizados e executados num ambiente onde o código de desenvolvimento é regularmente enviado, mesmo antes de o DoD da funcionalidade ser alcançado. Aqui, as falhas nos testes não indicam um defeito, mas sim fornecem uma visão antecipada sobre quais partes da funcionalidade ainda não estão implementadas ou totalmente funcionais.

Com pipelines de entrega contínua e uma estratégia de ramificação refinada implementada, onde os ramos de funcionalidades são frequentemente unidos ao ramo principal e implementados na cloud, configurámos um ambiente dedicado onde estes testes de sistema automatizados poderiam ser executados continuamente.

Feedback Mais Rápido com Testes Automatizados

Esta abordagem permitiu à QA do sistema iniciar a validação mais cedo, tornando os testes mais rápidos e fornecendo feedback mais rápido à equipa de desenvolvimento. Em vez de esperar até que uma funcionalidade seja marcada como concluída, os testes agora são executados 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 de casos de teste exigiu repensar as estratégias de teste.

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

Embora a adoção completa do BDD desde o início da criação da história de utilizador ainda esteja em andamento, melhorámos a colaboração entre as equipas de SQA e desenvolvimento, alinhando-as precocemente no processo.

Alinhar o SQA com o Desenvolvimento: A Influência das Topologias de Equipa

Para tal, 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 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 é executada continuamente à medida que o código é desenvolvido.

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

Conclusão

Esta melhoria reforça um princípio central do DevOps — abordar a transformação ao considerar as competências de Ferramentas, Arquitetura e Pessoas, enquanto se foca no fluxo. Ao automatizar o QA do sistema, integrar os testes mais cedo no ciclo e alinhar as equipas de forma mais eficaz, reduzimos significativamente o gargalo entre o desenvolvimento e a validação do sistema, acelerando os ciclos de feedback e tornando as implementações mais fluidas.

A Concluir a Série

Ao concluirmos a 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 sobre o anterior para impulsionar uma transformação significativa.

Aqui está um breve resumo da nossa série:

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

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

Mantenha a curiosidade. Mantenha-se iterativo. E, o mais importante, mantenha-se ligado.

Subscrever o Blogue da Freyr