Organizando o Desenvolvimento de Software: A Importância do Git Workflow
Os sistemas de controle de versões (VCS — Version Control System) evoluíram muito desde sua criação, abraçando cada vez mais as necessidades do desenvolvimento de software. Hoje, com eles, somos capazes de rastrear mudanças, desenvolver de forma colaborativa, isolar trabalhos em andamento, mesclar mudanças, fazer integração e entrega contínua (CI/CD) e, nos sistemas mais recentes baseados em Git, trabalhar com desenvolvimento descentralizado. Com tantas funcionalidades, não é surpresa que acabaram se tornando uma das ferramentas mais importantes na engenharia de software.
Apesar de toda a sua importância, utilizar as funcionalidades dos VCS sem a presença de um fluxo de trabalho padronizado pode não resultar em grandes vantagens. É possível utilizar essas ferramentas sem um padrão definido, mas a ausência dele limita significativamente a eficiência e a segurança.
Estabelecer um fluxo de trabalho padrão é essencial, já que as funcionalidades dos VCS são projetadas para se alinhar a um esquema de trabalho. Sem esse esquema, como podemos usar essas ferramentas de maneira eficiente?
Vamos considerar algumas dúvidas comuns do dia a dia, que nos ajudarão a compreender a importância da padronização e o impacto dela no ciclo de desenvolvimento.
- Qual branch deve ser utilizada para iniciar o trabalho?
- A main/master branch está atualizada com a última release?
- Quando devo fazer merge com a branch main/master?
- Qual branch devo usar para correções em produção?
- Quando é apropriado criar uma tag?
- Quando devo abrir um Pull/Merge Request?
Embora muitas vezes subestimadas, essas dúvidas são sintomas de problemas que geram impactos significativos na eficiência da equipe. Os termos técnicos podem ocultar a real essência dessas dúvidas. Mas elas estão diretamente ligadas às fases do fluxo de trabalho de uma equipe de desenvolvimento.
Podemos simplificar boa parte delas em algo como, “por onde eu começo meu trabalho?”, “o que faço para finalizar meu trabalho?” ou até mesmo “quando eu coloco meu trabalho para revisão?”.
Como podemos ver, essas atividades são parte da rotina de toda equipe de desenvolvimento; elas são executadas diversas vezes ao dia. Se a equipe ainda não sabe como realizá-las, então temos um grande problema e ao mesmo tempo uma grande oportunidade de aumentar a produtividade.
Imagine um cenário onde essas dúvidas não existem, devido a clareza sobre como e quando essas atividades são realizadas. Além do tempo economizado em discussões, tomadas de decisão e retrabalho, também ganhamos de brinde menos problemas em produção.
Como assim, menos problemas em produção? A inexistência de um fluxo de trabalho padronizado também exerce influência direta sobre a frequência dos problemas em produção. Considere, por exemplo, esta situação comum: um problema urgente surge em produção e precisa ser resolvido imediatamente. O desenvolvedor encarregado da correção se depara com a decisão crítica de escolher qual versão do software utilizará para corrigir. Sem um processo bem definido para orientar esta escolha, o risco de optar por uma versão inadequada aumenta consideravelmente. Imagine, por exemplo, que o desenvolvedor, por falta de diretrizes claras, escolhe uma versão ainda em desenvolvimento. Essa escolha pode inadvertidamente introduzir funcionalidades incompletas ou instáveis em produção, agravando o problema inicial. Embora possa ser fácil atribuir o problema a um erro isolado do desenvolvedor, na realidade, é a carência de um processo estruturado e bem delineado que representa o verdadeiro risco, criando um cenário propenso à falhas e complicações.
Agora que compreendemos os impactos indesejados causados pela ausência de um fluxo de trabalho padronizado no VCS, vamos investigar como podemos preveni-los. Nosso foco é ampliar a produtividade da equipe e, ao mesmo tempo, reduzir os problemas em produção, estabelecendo um fluxo de trabalho padronizado.
Padronizando o fluxo de trabalho com Git Workflow
O Git, ao longo das últimas décadas, se estabeleceu como o sistema de controle de versões (VCS) mais popular, sendo fundamental tanto no desenvolvimento de software privado quanto no open source. Com sua ampla adoção, surgiu o conceito “Git Workflow”, que pode ser entendido como o fluxo de trabalho padrão dentro do Git. Existem diversos Git Workflows disponíveis nas comunidades de desenvolvimento, eles podem ser utilizados integralmente ou como base para a criação de workflows personalizados, conforme as necessidades específicas do projeto, equipe ou até mesmo empresa.
Por serem bastante testados e aprovados, os Git Workflows mais populares são uma excelente base de partida para seus projetos. É uma boa ideia considerá-los antes de nos aventurarmos na criação de um totalmente novo.
Apesar de o termo “Git Workflow” estar fortemente ligado a aspectos técnicos, é crucial lembrar que seu objetivo principal é atender ao processo de desenvolvimento e lançamento de versões no projeto.
Portanto, analisaremos os Git Workflows focando em quatro aspectos fundamentais dos projetos de software. Manter esse foco vai ajudar a fazer uma escolha alinhada com as necessidades do seu projeto sem nos perdermos em detalhes menos importantes. Nossos quatro aspectos chaves são:
- Tamanho da equipe
- Complexidade do Projeto e Requisitos de Lançamento
- Gerenciamento de Riscos
- Frequência de Lançamentos
Vamos agora conhecer os Git Workflows mais populares e como cada um deles se encaixa com cada um dos aspectos.
Git Flow
Criado em 2010 por Vincent Driessen, o Git Flow enfatiza a separação clara de branches para desenvolvimento, lançamentos e manutenção, favorecido em projetos de software complexos.
- Tamanho da equipe: É indicado para equipes maiores. Sua estrutura mais complexa de branches consegue isolar diversas linhas de desenvolvimento simultaneo, fazendo com que seja possível muitas pessoas trabalharem em paralelo.
- Complexidade do Projeto e Requisitos de Lançamento: É ideal para projetos de alta complexidade, onde é importante gerenciar múltiplas versões ou lançamentos com ciclos extensos. Devido a sua estrutura para suportar a complexidade, o gerenciamento de sua estrutura exige mais esforço, portanto, ele se adequa melhor a lançamentos mais espaçados.
- Gerenciamento de Riscos: Eficaz para minimizar riscos, devido à sua natureza estruturada, possuir muitas branches com propósitos especificos e alto nível de isolamento, mas o esforço de mesclagem entre branches aumenta.
- Frequência de Lançamentos: É mais adequado para ciclos de lançamento menos frequentes e mais planejados, dada a sua estrutura mais formal para gerenciar releases.
Github Flow
Foi desenvolvido pelo GitHub, enfatiza a entrega contínua com branches de curta duração, ideal para desenvolvimento ágil e implantações rápidas.
- Tamanho da equipe: Se destaca em equipes menores. Devido a sua simplicidade, para que o desenvolvimento paralelo funcione bem, as práticas e cultura do desenvolvimento incremental devem estar bem estabelecidas na equipe.
- Complexidade do Projeto e Requisitos de Lançamento: Mais adequado para projetos com uma estrutura menos complexa, onde os lançamentos são mais frequentes e menos cerimoniosos. Ele facilita um ciclo de desenvolvimento contínuo, sendo ideal para projetos que não requerem uma gestão detalhada de múltiplas versões simultâneas.
- Gerenciamento de Riscos: Ao encorajar atualizações frequentes e incrementais, pode reduzir o risco de erros significativos. No entanto, pode ser menos apropriado para ambientes que exigem alta estabilidade.
- Frequência de Lançamentos: Se alinha bem com projetos que têm um ritmo acelerado de lançamentos. Ele suporta a integração e entrega contínua, permitindo uma rápida adaptação e resposta às mudanças.
Gitlab Flow
Criado pelo GitLab, enfatiza a relação entre branches e ambientes de deploy, integrando funcionalidades para deploy contínuo com um sistema de permissões detalhado, tornando-o ideal para fluxos de trabalho que requerem gestão rigorosa de versões em ambientes variados.
- Tamanho da equipe: Este modelo se adequa a equipes maiores. Devido a sua estrutura para suportar fluxos de trabalho mais complexo, ele promove um bom nível de isolamento do trabalho em andamento.
- Complexidade do Projeto e Requisitos de Lançamento: É adequado para projetos que necessitam de uma gestão de deploy contínua e um controle de versão rigoroso, especialmente em ambientes complexos, como projetos com múltiplos ambientes de produção.
- Gerenciamento de Riscos: Oferece uma gestão de riscos moderada que não é tão rigorosa quanto o Git Flow, mas mais controlada do que o GitHub Flow ou o Trunk-Based Development.
- Frequência de Lançamentos: Se alinha bem com projetos que têm uma frequência moderada de lançamentos. Isso o coloca entre o GitHub Flow/Trunk-Based Development (lançamentos frequentes) e o Git Flow (planejamento detalhado).
Trunk Based Workflow
Ganhando popularidade com as metodologias ágeis e CI/CD nos anos 2000, o Trunk-Based Development se caracteriza por integrações constantes na base principal e é ideal para equipes ágeis que buscam lançamentos rápidos e frequentes.
Nota: Apesar desse workflow ser parecido com o Github Flow, ele permite que commits sejam feitos diretamente na branch prinicipal o que não acontece no Github Flow e essa diferença acaba alterando outras premissas que estruturam o modelo.
- Tamanho da equipe: Adequado para equipes menores e mais ágeis que podem colaborar de perto.
- Complexidade do Projeto e Requisitos de Lançamento: Melhor para projetos com ciclos de lançamento simplificados. Ele favorece a entrega rápida e contínua, com menos ênfase em ciclos de lançamento complexos e manutenção de múltiplas versões em produção. É ideal para ambientes que buscam agilidade e onde as atualizações podem ser lançadas a qualquer momento.
- Gerenciamento de Riscos: Embora favoreça a agilidade e a entrega rápida, pode haver um risco maior de instabilidade devido às frequentes mudanças no trunk/master. Uma forte cultura de testes automatizados e integração contínua é essencial para mitigar esses riscos.
- Frequência de Lançamentos: Se destaca em cenários com lançamentos frequentes e rápidos. A ideia é integrar pequenas mudanças na base de código principal (trunk/master) de forma contínua, o que permite lançamentos quase imediatos de novas funcionalidades e correções.
Os Git Workflows que examinamos servem a diferentes necessidades de projetos. Com os quatro aspectos selecionados, percebemos que alguns se ajustam melhor a equipes menores, enquanto outros são mais adequados para equipes maiores. Por exemplo, a característica “Frequência de Lançamentos” revela que certos workflows são ideais para projetos com lançamentos frequentes, enquanto outros se adaptam melhor a lançamentos menos frequentes e mais complexos. Apesar dessas diferenças, não há uma resposta única e correta; o que prevalece é a necessidade do seu projeto.
Pode ser que nenhum dos workflows existentes atenda completamente às especificidades do seu projeto, talvez seja necessário avaliar trade-offs e fazer a melhor escolha para o momento atual. Independentemente da escolha feita, é fundamental monitorar o desempenho da equipe e verificar se o workflow está gerando bons resultados. Se necessário, faça revisões ou adaptações. O mais importante é que o Workflow escolhido esteja em harmonia com as necessidades e o ritmo do seu projeto e equipe.
