3 min de leitura
No Capítulo 4: Monitorizar o Que Importa – KPIs e Painéis, explorámos como a visualização do fluxo de trabalho e a definição dos KPIs corretos nos ajudaram a identificar estrangulamentos e a alinhar as nossas equipas em torno da entrega de valor. Com uma melhor visibilidade do nosso pipeline DevOps, começámos a colocar questões mais profundas, não apenas sobre onde estavam os estrangulamentos, mas por que razão estavam a acontecer.
No Capítulo 5, debruçamo-nos sobre uma das mudanças técnicas e de processos mais significativas no nosso percurso de transformação: o aperfeiçoamento da nossa estratégia de ramificação e a ativação da implementação contínua. Estas alterações foram fundamentais para resolver os atrasos persistentes entre o desenvolvimento e a produção.
Identificar o Novo Estrangulamento
Analisar o fluxo de trabalho e identificar estrangulamentos onde o trabalho se acumula tem sido um aspeto fundamental para alcançar a nossa transformação DevOps. Este foco no fluxo está no centro de como aplicámos o triângulo DevOps: ferramentas, arquitetura e pessoas, no sentido de alcançar uma entrega mais rápida e fiável.
À medida que avançávamos na melhoria da testabilidade com o aumento da cobertura de testes unitários e de testes automatizados, constatámos que a qualidade do código estava a melhorar, mas o estrangulamento continuava na fase de testes scrum. Apesar dos progressos na automação de testes, o trabalho continuava a acumular-se e o estrangulamento deslocou-se do desenvolvimento para os testes ao nível do sistema. Os indicadores chave de desempenho (KPIs) mostravam que o trabalho em curso por equipa durante o desenvolvimento estava a diminuir, mas o código continuava a ficar retido no ponto de transição para os testes de sistema. Em última análise, este atraso impedia-nos de alcançar um fluxo fluido.
A Causa Raiz: Estratégia de Ramificação e Uniões Atrasadas
A análise revelou que a causa raiz da acumulação residia na nossa estratégia de ramificação. Os programadores e testadores estavam a criar ramos de funcionalidades a partir do ramo principal ao iniciar novas funcionalidades. À medida que o código evoluía, os engenheiros enviavam as suas alterações para ramos de funcionalidades remotos para unir o seu trabalho com o dos outros. No entanto, este código não estava a ser integrado de volta no ramo principal com a frequência necessária.
Os pipelines de CI/CD estavam configurados no ramo principal, executando testes automatizados e implementando na nuvem, seguidos de testes de regressão. Contudo, dado que as alterações mais recentes não eram enviadas regularmente para o ramo principal, as execuções do pipeline corriam com código desatualizado, tornando-as redundantes e ineficazes.
A Solução: Ramos de Funcionalidades de Curta Duração
Para resolver esta questão, compreendemos que era necessário afinar a estratégia de ramificação. Embora existam vantagens e desvantagens em diferentes estratégias de ramificação, decidimos continuar com a estratégia de ramos de funcionalidades, mas com um ajuste fundamental: ramos de funcionalidades de curta duração que são integrados de volta no ramo principal com maior frequência.
A estratégia de ramos de funcionalidades de curta duração oferece várias vantagens, sendo o benefício mais crítico a melhoria do fluxo e a resolução dos estrangulamentos no ciclo de desenvolvimento. Ramos de menor duração asseguram que as uniões de código são mais fáceis, rápidas e menos propensas a erros. Esta abordagem também permite um feedback mais rápido, o que melhora a qualidade geral e a velocidade do processo de desenvolvimento.
Implementação Contínua: O Desafio do Pipeline
Configurar pipelines de implementação contínua robustos é uma tarefa complexa que requer uma abordagem focada e incremental. Na nossa experiência, contar com uma equipa de plataforma dedicada para configurar e manter estes pipelines é a abordagem recomendada, em vez de fazer com que cada equipa scrum trabalhe neles individualmente. Embora a responsabilidade final pelos pipelines de entrega contínua deva pertencer às equipas scrum, a tarefa inicial de os configurar beneficia enormemente de uma equipa de plataforma dedicada.
Equipa de Plataforma: Reduzir a Carga Cognitiva e Promover o Foco
Para encontrar inspiração na estruturação da nossa equipa de plataforma, baseámo-nos na obra Team Topologies de Matthew Skelton e Manuel Pais. O livro enfatiza a importância de contar com uma equipa de plataforma dedicada encarregue de configurar e gerir a infraestrutura — no nosso caso, os pipelines de integração contínua (CI/CD). Esta estrutura permite que as equipas de scrum se concentrem no desenvolvimento de funcionalidades, beneficiando simultaneamente de uma configuração de pipeline estável e padronizada.
Como refere o livro:
“A equipa de plataforma é responsável por construir e manter a plataforma interna utilizada pelas equipas orientadas para o fluxo de valor para entregar o seu trabalho. O objetivo da plataforma é reduzir a carga cognitiva dessas equipas, permitindo-lhes focar-se na entrega de valor.”
Ao centralizar a responsabilidade pelos pipelines, conseguimos criar uma plataforma comum e partilhada da qual as equipas orientadas para o fluxo de valor podiam depender. Isto permitiu-nos reduzir a carga cognitiva das equipas de desenvolvimento, permitindo-lhes focar-se na entrega de valor em vez de lidarem com questões de infraestrutura.
Evolução da Plataforma para Melhoria Contínua
Ter uma equipa de plataforma não se cinge apenas à configuração de pipelines; consiste em evoluir a infraestrutura partilhada e as ferramentas ao longo do tempo. Uma equipa de plataforma dedicada está na melhor posição para introduzir melhorias incrementais no pipeline de entrega contínua, garantindo que este se mantém alinhado com as necessidades das equipas e se adapta à medida que crescemos e escalamos. Esta evolução contínua assegura que a plataforma permanece fiável, escalável e eficiente, capacitando as nossas equipas para trabalharem ao mais alto nível.
Seguinte: Automação e Feedback
Com a ramificação simplificada e as implementações a decorrer fluidamente, passamos à última etapa da nossa jornada de DevOps: Automação e Feedback. No próximo e último capítulo, exploraremos como o fecho do ciclo com contributos automatizados e feedback rápido transformou a forma como as nossas equipas operam.
Fique atento!
