Para equipes de desenvolvimento de software ágil e de DevOps, o Git é o sistema de controle de versão de fato e parte essencial da Cadeia de ferramentas do DevOps. Esse projeto de código aberto e com ótimo suporte é flexível o suficiente para dar assistência a vários fluxos de trabalho que atendem às necessidades de qualquer equipe de software. A natureza distribuída — em vez de centralizada — confere a ele características de desempenho superior e dá aos desenvolvedores a liberdade de testar no local e publicar as alterações apenas quando elas estiverem prontas para serem distribuídas para a equipe.
Além dos benefícios de flexibilidade e distribuição, existem funções-chave do Git que oferecem suporte e aprimoram as equipes de desenvolvimento ágil e DevOps. Pense no Git como um componente do desenvolvimento ágil e DevOps: as alterações podem ser movidas para baixo no pipeline de implementação com mais rapidez do que trabalhando com versões monolíticas e sistemas de controle de versão centralizados. O Git funciona do mesmo jeito que as equipes ágil e DevOps trabalham (e se esforçam para trabalhar).
Dica 1: Comece a pensar sobre as tarefas como ramificações do Git
O Git entra em ação depois que as funções são aprimoradas, adicionadas ao roteiro do produto e a equipe de desenvolvimento está pronta. Mas aqui vai uma apresentação resumida sobre desenvolvimento ágil de funções: produto, design, garantia de qualidade (QA) e engenharia realizam a reunião inicial para apresentar entendimento compartilhado do que a função vai ser (pense em requisitos), escopo do projeto e em quais tarefas a função precisa ser dividida para ser concluída. Essas tarefas, também conhecidas como histórias do usuário, são então designadas a desenvolvedores individuais.
O Git começa a se encaixar no fluxo de trabalho ágil neste momento. Na Atlassian, a gente cria novas ramificações para cada item. Sejam novas funções, atualizações de segurança ou pequenas melhorias no código, cada alteração de código recebe a própria ramificação.
A ramificação é simples e permite que as equipes colaborem com facilidade dentro de uma base de código central. Quando um desenvolvedor cria uma ramificação, ele tem uma versão própria isolada da base de código para fazer alterações. Para as equipes ágeis, quer dizer que: ao dividir funções em histórias de usuários e, depois, em ramificações, a equipe de desenvolvimento tem a possibilidade de lidar cada tarefa em separado e trabalhar com mais eficiência no mesmo código, mas em repositórios diferentes. Não há duplicação de trabalho, pois as pessoas conseguem se concentrar em partes pequenas do trabalho em repositórios separados do repositório principal, já que não há tantas dependências reduzindo a velocidade do processo de desenvolvimento.
Há outros tipos de ramificação Git além da ramificação de tarefa e eles não são mutuamente exclusivos. É possível criar ramificações para uma liberação, por exemplo. Isso permite que os desenvolvedores estabilizem e melhorem o trabalho programado para uma liberação específica, sem a necessidade de esperar outros desenvolvedores que estão trabalhando em liberações futuras.
Assim que tiver criado uma ramificação de versão, você precisa fazer mesclagens regulares na ramificação principal para garantir que a função seja usada em versões futuras. Para minimizar a sobrecarga, é melhor criar a ramificação de versão o mais próximo possível da data programada para o lançamento.
Dica 2: várias ramificações são testáveis individualmente, então aproveite
Assim que as ramificações forem consideradas concluídas e prontas para as revisões de código, o Git executa outra função essencial no fluxo de trabalho de desenvolvimento ágil: o teste. Equipes ágeis e de DevOps bem-sucedidas praticam revisões de código e testes automatizados de configuração (integração contínua ou entrega contínua). Para ajudar com o teste e as revisões de código, os desenvolvedores podem notificar com facilidade o restante da equipe de que a ramificação está pronta para revisão e que precisa ser revisada por meio de uma solicitação pull. Resumindo, uma solicitação pull é uma maneira de pedir a outro desenvolvedor que mescle uma de suas ramificações na ramificação principal e de informar que está tudo pronto para testes.
Com as ferramentas certas, o servidor de integração contínua pode compilar e testar as solicitações pull antes de mesclar. Assim você pode confiar que a mesclagem não vai ter problemas. Essa confiança facilita o redirecionamento de correções de bugs e conflitos em geral, pois o Git sabe a diferença entre a ramificação e o código mestre, uma vez que as ramificações divergiram.
Uma ramificação de versão de longa duração que não foi mesclada à ramificação principal pode prejudicar sua capacidade de ser ágil e iterar. Se você tem uma ramificação de função de longa duração, não se esqueça de que na prática você tem duas versões divergentes do seu código base, o que vai resultar em mais correções de bugs e conflitos. A melhor solução é ter ramificações de função de curta duração. Essa operação pode ser alcançada com a divisão das histórias do usuário em tarefas menores, planejamento cuidadoso de sprint e mesclagem de código antecipada para lançar como funções obscuras.
Dica 3: o Git fornece transparência e qualidade ao desenvolvimento ágil
O Git/história ágil é sobre eficiência, testes, automação e agilidade geral. Depois de mesclar ramificações à ramificação principal, o fluxo de trabalho ágil está concluído. Da mesma forma, mesclar o código por meio de solicitações pull significa que quando o código for concluído, você vai ter a documentação para saber com confiança que o trabalho está classificado com a cor verde, que outros membros da equipe finalizaram o código e que ele está pronto para ser lançado. Assim as equipes ágeis podem continuar se movendo com rapidez e confiança para lançar com frequência: o sinal de excelência das equipes ágeis.
Adotar uma frequência regular de liberação é fundamental para o desenvolvimento ágil. Para fazer o Git funcionar no seu fluxo de trabalho ágil, é necessário garantir que a ramificação principal esteja sempre verde. Dessa forma, se uma função não estiver pronta, você deve esperar até a próxima liberação. Se praticar ciclos de liberação mais curtos, não vai haver nenhum problema.
