Já falamos por aqui sobre como trabalhar com Git, mas ter um bom fluxo de branchs e features no seu Git, que garanta uma entrega ágil e segura para a sua equipe, pode ser um pouco mais complicado do que parece. No artigo de hoje, vamos contar como gerenciamos o Git por aqui na Devnology.
Dificuldades de um bom fluxo no Git
Algo bem popular no gerenciamento de projetos no Git é ter as conhecidas branchs develop para um ambiente de desenvolvimento,homolog para um ambiente de testes e finalmente main para o ambiente de produção do nosso projeto. Um modelo bastante comum de Git Flow é a cada nova demanda uma branch feature é criada, e finalizado é feito um merge para a branch de desenvolvimento. Terminada o processo de desenvolvimento, com a branch develop é feito um merge para a branch homolog para os testes. Concluído os testes, a branch main é atualizada com a branch homolog. Assim vemos um fluxo muito claro de feature → develop → homolog → main.
Este processo faz bastante sentido em um momento inicial quando o seu projeto ainda está em desenvolvimento e não foi lançado em produção, mas a partir do momento em que o projeto está no ar, pessoas estão utilizando e novas melhorias continuam sendo feitas, este fluxo pode dificultar bastante a sua entrega.
Vamos imaginar um momento em que seu projeto está no ar, e há 3 novas melhorias sendo desenvolvidas. As 3 novas melhorias, nas branchs feature1, feature2 e feature3 passaram pelo develop e foram para a branch homolog para que o processo de teste se inicie. Durante os testes a melhoria 1 e a melhoria 3 foram aprovadas, mas a melhoria 2 precisou de ser feito um ajuste e a branch feature2 voltou para o início do processo. Agora, você tem a feature1 e feature3 aprovadas em homolog prontas para subir em produção, mas seguindo este fluxo comum, em que você não pode fazer uma atualização homolog → main porque a branch homolog está “suja”, pois também contem a feature2 que ainda não foi aprovada. Você deverá parar todo seu processo de entrega, e esperar que seja retestado e aprovada para fazer um novo release em produção.
Se você quer agilidade na sua entrega esse modelo não é suficiente. Pense que se a melhoria 1 e a melhoria 3 estão prontas, você já deveria poder atualizá-las em produção. Já pensou se esse ajuste que será feito na melhoria 2 é mais complexo do que parece, e demore mais de 1 mês?
Um modelo de estratégia para agilidade na entrega
Para melhorar a nossa entrega, focamos em um modelo de “independência” entre as branchs. Nessa nova estratégia, quebramos as relações entre os de ambiente de desenvolvimento develop, homolog e main. Essas branchs não entram mais uma em contato com a outra, e o fluxo develop → homolog → main não existe mais. Cada branch de melhoria sobe independente uma da outra, em um fluxo como: feature→ develop , depois feature → homolog e por fim feature → main.
Voltando ao nosso exemplo de 3 melhorias sendo desenvolvidas paralelamente, em que as 3 melhorias estão em teste no ambiente homolog, mas apenas as melhorias 1 e 3 foram aprovadas: podemos fazer feature1 → main e feature3→ main imediatamente, sem aguardar para que a feature2 seja ajustada.
Possíveis problemas e como contornar
Nossa grande preocupação neste fluxo é manter a branch “limpa”, ou seja, a branch feature conter apenas a melhoria onde ela se refere.
Com tudo ocorrendo bem, isso acontece naturalmente: não misturamos as branchs feature e elas sobem uma de cada vez para cada ambiente. Mas ainda pode ocorrer um conflito —quando as mesmas branchs mexem no mesmo arquivo.
Em exemplo: foi feito um merge para a branch feature1 em homolog. Algum tempo depois, foi também feito um merge para a branch feature2 em homolog. Neste momento foi entregue um alerta de conflito. Para resolver um conflito, basta que a feature2 fosse atualizada com a branch homolog e o conflito resolvido internamente, mas perceba que se fizer isso a branch feature2 irá também conter a branch feature1, pois ela estava em homolog naquele momento. Isso faz com que sua branch feature2 fique suja e pode ser um grande problema. Caso ocorra uma situação como em nossos exemplos, de que a feature2 seja aprovada, mas a feature1 ainda precise de ajustes, você não poderia mais subir a feature2 em produção, pois ela irá acabar levando em conjunto a feature1.
Este não é um problema impossível de ser resolvido. Basta duplicar, criando uma branch secundária, com base na feature2 apenas para a resolução de conflito, algo como feature2-homolog. Use essa nova branch para resolver o conflito, e realize o merge de feature2-homolog para homolog. Com isso, a feature2 continua limpa e pode ser realizado um merge para a main sem mais preocupações —perceba até que feature2-homolog foi usada em apenas um único momento.
E se a melhoria 2 precisar de um ajuste? Resolva o ajuste naturalmente na branch feature2. Continue com o fluxo normalmente, envie-a para develop e ao chegar em homolog, onde ocorreu um conflito anteriormente, atualize a sua branch feature2-homolog com o ajuste, e continue usando essa branch para resolução de conflito.
Perceba que nosso grande problema são em casos de conflitos. Uma boa dica é criar uma rotina de atualização das branchs develop e homolog. Essas branchs devem sempre ser independentes, mas não é bom que elas se percam no fluxo e acabem sempre por indicar conflitos. Confira estes ambientes de tempo em tempo e os deixem sempre atualizados com a main.
Como se adaptar a este fluxo
Na prática, este fluxo “ágil” funciona bastante bem e podemos ver resultados rapidamente após sua implementação. Para uma boa implementação deste fluxo é preciso uma mudança na mentalidade e comprometimento da equipe. Tudo deve ser feito com bastante cuidado para evitar problemas, mas a partir do momento que as ideias se encaixam tudo passa a fluir naturalmente.
Lembre-se sempre de criar suas branchs com base na main e siga o fluxo com bastante calma, uma vez para develop, outra para homolog e finalmente para a main. Jamais resolva conflitos diretamente na branch feature e tudo ocorrerá bem.
Devo dizer também que nenhum fluxo ou metodologia é uma “lei”. Para uma real boa adaptação é importante que pensar na sua equipe, no projeto e principalmente na experiência em que foi construída ao redor destes dois pontos. Traga os métodos e conhecimentos que você tem estudado para a sua própria realidade.
Nos próximos projetos da devGo tentaremos levar este fluxo a prática durante a etapa de desenvolvimento. Acompanhe nosso canal no Discord, inscreva-se em nossa newsletter e acompanhe os nossos conteúdos de perto.