3 min ler
Em Capítulo 4: Monitorizar o que interessa - KPIs e Dashboardsexplorámos a forma como a visualização do fluxo de trabalho e a definição dos KPIs corretos us ajudaram a detetar estrangulamentos e a alinhar as nossas equipas em torno da entrega de valor. Com melhor visibilidade do nosso pipeline de DevOps, começamos a fazer perguntas mais profundas - não apenas onde estavam os gargalos, mas por que eles estavam acontecendo.
No Capítulo 5, mergulhamos em uma das mudanças técnicas e de processo mais significativas em nossa jornada de transformação: refinar nossa estratégia de ramificação e permitir a implantação contínua. Essas mudanças 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 os estrangulamentos onde o trabalho se está a acumular tem sido um aspeto fundamental para alcançar a nossa transformação DevOps. Este enfoque no fluxo está no centro da forma como aplicámos o triângulo DevOps - ferramentas, arquitetura e pessoas - para conseguir uma entrega mais rápida e fiável.
À medida que progredimos na melhoria da testabilidade com o aumento da cobertura dos testes unitários e da automatização dos testes, descobrimos que a qualidade do código estava a melhorar, mas o estrangulamento continuava na fase de testes scrum. Apesar dos progressos na automatização dos testes, o trabalho continuava a acumular-se e o estrangulamento passou do desenvolvimento para os testes ao nível do sistema. Os indicadores-chave de desempenho (KPIs) mostraram que o trabalho em curso por equipa durante o desenvolvimento estava a diminuir, mas o código continuava a ficar preso no ponto de transição para os testes do sistema. Este atraso acabou por us impedir de alcançar um fluxo suave.
A causa principal: Estratégia de ramificação e fusões atrasadas
A análise revelou que a causa principal do atraso estava na nossa estratégia de ramificação. Os desenvolvedores e testadores estavam criando ramificações de recursos a partir da ramificação principal ao iniciar novos recursos. À medida que o código se desenvolvia, os engenheiros enviavam as suas alterações para ramos de funcionalidades remotos para fundir o seu trabalho com outros. No entanto, esse código não estava sendo mesclado de volta ao ramo principal com frequência suficiente.
Os pipelines de CI/CD foram configurados no ramo principal, executando testes automatizados e implantando na nuvem, seguidos de testes de regressão. No entanto, uma vez que as alterações mais recentes não estavam a ser enviadas regularmente para o ramo principal, as execuções do pipeline estavam a ser executadas em código desatualizado, tornando-as redundantes e ineficazes.
A correção: ramificações de recursos de curta duração
Para resolver isso, percebemos que era necessário um ajuste fino da estratégia de ramificação. Embora existam prós e contras para diferentes estratégias de ramificação, decidimos continuar com a estratégia de ramificação de recursos, mas com um ajuste importante: ramificações de recursos de curta duração que são mescladas de volta à ramificação principal com mais frequência.
A estratégia de ramificação de caraterísticas 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. Os ramos de vida mais curta garantem que as fusões de código sejam mais fáceis, mais 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.
Implantação contínua: O desafio do pipeline
A configuração de pipelines de implementação contínua robustos é uma tarefa complexa que requer uma abordagem focada e incremental. Na nossa experiência, ter uma equipa de plataforma dedicada para configurar e manter estes pipelines é a abordagem recomendada, em vez de ter cada equipa scrum a trabalhar neles individualmente. Embora a eventual propriedade dos pipelines de entrega contínua deva pertencer às equipas scrum, a tarefa inicial de os configurar beneficia muito com uma equipa de plataforma dedicada.
Equipa da plataforma: Reduzir a carga cognitiva e permitir a concentração
Para nos inspirarmos na estruturação da nossa equipa de plataforma, recorremos ao livro Team Topologies de Matthew Skelton e Manuel Pais. O livro enfatiza a importância de ter uma equipa de plataforma dedicada que seja responsável pela configuração e gestão da infraestrutura - nonosso caso, os pipelines de CD. Esta estrutura permite que as equipas scrum se concentrem no desenvolvimento de funcionalidades, enquanto beneficiam de uma configuração de pipeline estável e padronizada.
Como diz o livro:
"A equipa da plataforma é responsável pela criação e manutenção da plataforma interna que as equipas alinhadas com o fluxo utilizam para realizar o seu trabalho. O objetivo da plataforma é reduzir a carga cognitiva das equipas alinhadas com o fluxo de trabalho, para que possam concentrar-se na criação de valor."
Ao centralizar a responsabilidade pelos pipelines, conseguimos criar uma plataforma comum e partilhada da qual as equipas alinhadas com o fluxo podiam depender. Isto us reduzir a carga cognitiva das equipas de desenvolvimento, permitindo-lhes concentrarem-se na entrega de valor em vez de lidarem com questões de infraestrutura.
Evolução da plataforma para a melhoria contínua
Ter uma equipa de plataforma não se trata apenas de configurar os pipelines; trata-se de fazer evoluir a infraestrutura e as ferramentas partilhadas ao longo do tempo. Uma equipa de plataforma dedicada está na melhor posição para fazer melhorias incrementais no pipeline de entrega contínua, garantindo que este se mantém alinhado com as necessidades das equipas e que se adapta à medida que crescemos e escalamos. Esta evolução contínua garante que a plataforma se mantém fiável, escalável e eficiente - permitindo queas nossas equipas trabalhem no seu melhor.
A seguir: Automatização e feedback
Com a ramificação simplificada e as implantações fluindo, nos voltamos para a fronteira final em nossa jornada DevOps: Automação e feedback. No próximo e último capítulo, vamos explorar como fechar o ciclo com informações automatizadas e feedback rápido transformou a forma como as nossas equipas funcionam.
Fique atento!
