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 é 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 profissional:
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, você precisa fazer mesclagens regulares na ramificação 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 é 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.

Dica profissional:

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 recurso 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 recurso 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 recursos obscuros.

Dica 3: o Git fornece transparência e qualidade ao desenvolvimento ágil

Dica profissional:

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 um recurso não estiver pronto, você deve esperar até a próxima liberação. Se praticar ciclos de liberação mais curtos, não vai haver nenhum problema.

a seguir
Branching