Quais são as melhores práticas do GitLab Flow?

Quando as equipes de desenvolvimento de software apressam a entrega, podem ter fluxos de trabalho confusos ou complexos. As empresas que migram de outro sistema de controle de versão estão mais propensas a lidar com processos desafiadores que podem atrasar o desenvolvimento. Quando as equipes usam o GitLab Flow, podem usar o desenvolvimento orientado por funcionalidades e branches de recurso com rastreamento de problemas para garantir que todos os membros da equipe trabalhem com eficiência. Usando essas dicas do GitLab Flow, as equipes de desenvolvimento de software podem simplificar seus processos e produzir um resultado mais eficiente e harmonioso.

Usar branches de recurso é uma maneira simples de desenvolver e manter o código-fonte limpo. Por exemplo, se uma equipe tiver migrado recentemente do SVN para o Git, ela estará acostumada com um fluxo de trabalho baseado em troncos. Ao usar Git, os desenvolvedores devem criar um branch para qualquer coisa em que estejam trabalhando, para que os colaboradores possam iniciar facilmente o processo de revisão de código antes de mesclar.

Alguns desenvolvedores configuram a CI para testar apenas os elementos mesclados no branch main. No entanto, isso acontece muito tarde no ciclo de desenvolvimento de software, e todas as partes envolvidas, desde desenvolvedores até gerentes de produto, devem ter sempre a certeza de que o branch main está estável e funcionando corretamente. É ineficiente que os desenvolvedores tenham que testar o main antes de começar a desenvolver novos recursos.

Ao trabalhar em um branch feature e adicionar novos commits, execute os testes imediatamente. Se os testes estiverem demorando muito, experimente executá-los em paralelo. Faça isso do lado do servidor em solicitações de merge, executando o conjunto de testes completo. Se houver um conjunto de testes para desenvolvimento e outro apenas para novas versões, vale a pena configurar testes [paralelos] e executar todos.

Não teste tudo no final de uma semana ou projeto. As revisões de código devem ocorrer o mais rápido possível, porque é mais provável que os desenvolvedores identifiquem problemas que possam causar problemas mais tarde no ciclo de vida. Como eles encontrarão problemas mais cedo, terão mais facilidade em criar soluções.

Se os desenvolvedores não quiserem implantar o main todas as vezes, eles podem criar um branch production. Em vez de usar um script ou fazê-lo manualmente, as equipes podem usar a automação ou ter um branch específico que acione uma implantação de produção.

Os desenvolvedores devem usar tags para que o CI execute uma ação em vez de fazer com que o CI altere o repositório. Se as equipes exigirem métricas detalhadas, elas devem ter um relatório do servidor detalhando novas versões.

Cada tag deve criar um novo lançamento. Essa prática garante um ambiente de desenvolvimento limpo e eficiente.

Ao enviar por push para um branch público, os desenvolvedores não devem rebaseá-lo, porque isso dificulta a identificação dos resultados dos testes e de melhoria, enquanto cherry picking. Às vezes, essa dica pode ser ignorada ao pedir a alguém para fazer squash e rebase no final de um processo de revisão de código para facilitar a reversão de algo. No entanto, em geral, a diretriz é que o código deve ser limpo e o histórico deve ser realista.

Essa dica evita branches longos. Os desenvolvedores verificam o branch main, compilam um recurso, criam uma solicitação de merge e usam o branch main como destino novamente. Eles devem fazer uma revisão completa antes de mesclar e eliminar qualquer etapa intermediária.

Depois de identificar um bug, uma ação problemática que alguém pode realizar é corrigi-lo na versão recém-lançada e não corrigi-lo no main. Para evitar isso, os desenvolvedores devem sempre avançar enviando por push a alteração no main e depois selecioná-la em outro branch patch-release.

Os desenvolvedores não devem apenas dizer o que fizeram, mas também por quê o fizeram. Uma tática ainda mais útil é explicar porque essa opção foi selecionada em detrimento de outras para ajudar futuros colaboradores a entender o processo de desenvolvimento. Escrever mensagens de commit descritivas é útil para revisões de código e desenvolvimento futuro.