Ramificação e Implementação Contínua

No Capítulo 4: Monitorizar o que importa – KPIs e Dashboards, explorámos como a visualização do fluxo de trabalho e a definição dos KPIs certos nos ajudaram a identificar gargalos e a alinhar as nossas equipas em torno da entrega de valor. Com uma melhor visibilidade do nosso pipeline DevOps, começámos a fazer perguntas mais profundas – não apenas onde estavam os gargalos, mas por que estavam a acontecer.

No Capítulo 5, aprofundamos uma das mudanças mais significativas a nível técnico e de processo na nossa jornada de transformação: refinando a nossa estratégia de ramificação e permitindo a implementação contínua. Estas mudanças foram cruciais para resolver atrasos persistentes entre o desenvolvimento e a produção.

Identificar o Novo Gargalo

Analisar o fluxo de trabalho e identificar gargalos 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 – para alcançar uma entrega mais rápida e fiável.

À medida que progredíamos na melhoria da testabilidade com o aumento da cobertura de testes unitários e de automação de testes, descobrimos que a qualidade do código estava a melhorar, mas o gargalo ainda estava na fase de testes scrum. Apesar do progresso na automação de testes, o trabalho continuava a acumular-se, e o gargalo passou do desenvolvimento para os testes de nível de 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 ainda ficava preso no ponto de transição para os testes de sistema. Este atraso acabou por nos impedir de alcançar um fluxo suave.

A Causa Raiz: Estratégia de Ramificação e Fusões Atrasadas

A análise revelou que a causa raiz do atraso residia na nossa estratégia de ramificação. Programadores e testadores estavam a criar ramificações de funcionalidades a partir da ramificação principal ao iniciar novas funcionalidades. À medida que o código era desenvolvido, os engenheiros enviavam as suas alterações para ramificações de funcionalidades remotas para fundir o seu trabalho com o de outros. No entanto, este código não estava a ser fundido de volta na ramificação principal com frequência suficiente.

Os pipelines de CI/CD foram configurados na ramificação principal, executando testes automatizados e implementando na cloud, seguidos por testes de regressão. No entanto, uma vez que as alterações mais recentes não estavam a ser enviadas para a ramificação principal regularmente, as execuções do pipeline estavam a ser realizadas em código desatualizado, tornando-as redundantes e ineficazes.

A Solução: Ramificações de Funcionalidades de Curta Duração

Para resolver isto, percebemos que era necessário ajustar a estratégia de ramificação. Embora existam prós e contras em diferentes estratégias de ramificação, decidimos continuar com a estratégia de ramificação de funcionalidades, mas com um ajuste fundamental: ramificações de funcionalidades de curta duração que são fundidas de volta na ramificação principal com mais frequência.

A estratégia de ramificação de funcionalidades de curta duração oferece várias vantagens, sendo o benefício mais crítico o fluxo melhorado e a resolução dos gargalos no ciclo de desenvolvimento. Ramificações de curta duração garantem que as fusõ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

A criação de pipelines de implementação contínua robustos é uma tarefa complexa que exige 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 cada equipa scrum trabalhar neles individualmente. Embora a responsabilidade final pelos pipelines de entrega contínua deva pertencer às equipas scrum, a tarefa inicial de os configurar beneficia grandemente de uma equipa de plataforma dedicada.

Equipa de Plataforma: Redução da Carga Cognitiva e Foco Aprimorado

Para nos inspirarmos na estruturação da nossa equipa de plataforma, recorremos a Team Topologies de Matthew Skelton e Manuel Pais. O livro enfatiza a importância de ter uma equipa de plataforma dedicada que é responsável por configurar e gerir a infraestrutura – no nosso caso, os pipelines de CD. Esta estrutura permite que as equipas scrum se concentrem no desenvolvimento de funcionalidades, beneficiando de uma configuração de pipeline estável e padronizada.

Conforme o livro afirma:

“A equipa de plataforma é responsável por construir e manter a plataforma interna que as equipas alinhadas por fluxo utilizam para realizar o seu trabalho. O objetivo da plataforma é reduzir a carga cognitiva para as equipas alinhadas por fluxo, para que estas se possam focar na entrega de valor.”

Ao centralizar a responsabilidade pelos pipelines, conseguimos criar uma plataforma comum e partilhada na qual as equipas alinhadas por fluxo podiam confiar. Isto permitiu-nos reduzir a carga cognitiva nas equipas de desenvolvimento, capacitando-as a focar-se na entrega de valor, em vez de se preocuparem 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 evoluir a infraestrutura partilhada e as ferramentas 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 se adapta à medida que escalamos e crescemos. Esta evolução contínua garante que a plataforma permanece fiável, escalável e eficiente – capacitando as nossas equipas a trabalhar no seu melhor.

A Seguir: Automação e Feedback

Com a ramificação simplificada e as implementações a fluir, voltamo-nos para a última fronteira na nossa jornada DevOps: Automação e Feedback. No próximo e último capítulo, iremos explorar como o fecho do ciclo com informações automatizadas e feedback rápido transformou a forma como as nossas equipas operam.

Fique atento!