O Git torna o desenvolvimento de software mais fácil

Três dicas para adequar o Git ao fluxo de trabalho ágil (e vice-versa)

Laura Daly Laura Daly
Buscar tópicos

Para equipes de desenvolvimento de software ágil e de DevOps, o Git é, de fato, o sistema de controle de versão. 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 profissional:

O Git é o sistema de controle de versão distribuído (DVCS). Ao contrário dos repositórios de CVS ou de subversão (SVN), o Git permite que os desenvolvedores criem a própria cópia pessoal do repositório da equipe, hospedado junto à base de código principal. Essas cópias são chamadas de bifurcações. Quando o trabalho é concluído na bifurcação, fica fácil trazer as alterações de volta para a base de código principal.

Ramificação Git | Coach Agile Atlassian

Dica 1: Comece a pensar sobre as tarefas como ramificações do Git

O Git entra em ação depois que os recursos são aprimorados, adicionados ao roteiro do produto e a equipe de desenvolvimento está pronta. Mas aqui vai uma apresentação resumida sobre desenvolvimento ágil de recursos: produto, design, garantia de qualidade (QA) e engenharia realizam a reunião inicial para apresentar entendimento compartilhado do que o recurso vai ser (pense em requisitos), escopo do projeto e em quais tarefas o recurso precisa ser dividido para ser concluído. 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 novos recursos, 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 recursos 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.

Dica profissional:

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, vai ser necessário fazer a mesclagem regular no branch principal para garantir que o recurso seja usado 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.

Visão detalhada da ramificação Git | Coach Agile Atlassian

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 é um modo de pedir a outro desenvolvedor que mescle as ramificações no branch principal e de informar que está tudo pronto para o teste.

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 ramificação e código mestre, uma vez que as ramificações divergiram.

Dica profissional:

Uma ramificação de recursos de longa execução que não é mesclada ao branch principal pode prejudicar a capacidade de ser ágil e iterar. Caso tenha uma ramificação de recursos de longa execução, você precisa se lembrar de que tem duas versões divergentes de base de código, o que vai resultar em mais correções de bugs e conflitos. Mas a melhor solução é ter ramificações de curta duração. Isso pode ser alcançado por meio da decomposição de histórias do usuário em tarefas menores, planejamento cuidadoso de sprint e mesclagem de códigos adiantada para lançar como recursos ocultos.

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 ao branch 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.

Dica profissional:

Adotar uma frequência regular de liberação é fundamental para o desenvolvimento ágil. Para fazer o Git funcionar em seu fluxo de trabalho ágil, é necessário garantir que sua ramificação principal esteja sempre verde. Isso significa que, se um recurso não estiver pronto, você deve esperar até a próxima liberação. Se praticar ciclos de liberação mais curtos, isso não será um problema.

a seguir
Branching