Representação de uma branch utilizando a ferramenta “Git”. Ícone retirado em Phosphor Icons.

Dentro do NÓS: Melhorando o ciclo de desenvolvimento

É comum que desenvolvedores atuem em projetos nos quais são os únicos responsáveis por impulsionar o progresso, independentemente do motivo para sua criação, seja para estudos ou para compartilhar ideias. No entanto, essa dinâmica muitas vezes não incentiva o desenvolvedor a configurar e organizar o projeto de maneira adequada, tornando o fluxo de desenvolvimento menos claro e, consequentemente, dificultando a participação de contribuições externas.

O projeto extensionista Nosso Olhar Solidário, que começou com um número reduzido de desenvolvedores, recentemente contou com a participação ativa de até oito colaboradores envolvidos na ação solidária, contribuindo com a escrita de código, relatórios de problemas e correção de bugs. Esse aumento no grupo de desenvolvedores trouxe desafios, uma vez que o fluxo anterior, que não utilizava as ferramentas Git e GitHub, mostrou-se ineficiente para o novo cenário.

Neste artigo, descreverei a implementação de um ciclo de desenvolvimento mais eficiente para aprimorar o fluxo geral da equipe, promovendo maior liberdade no trabalho conjunto. Isso será alcançado por meio da adoção de um fluxo Git (Git flow) mais sofisticado e da sistematização do uso de issues, assim como de Pull Requests para a revisão de códigos na plataforma GitHub.

Demonstração do website do projeto NÓS em um dispositivo móvel

O que é o projeto NÓS?

Nosso Olhar Solidário (NÓS) é um projeto sem fins lucrativos que visa ajudar o próximo. Para facilitar a conexão entre quem precisa de ajuda e quem deseja ajudar, foi desenvolvido primeiramente um aplicativo móvel que permite localizar facilmente oportunidades de doação e voluntários próximos. Seja para ajudar instituições ou pessoas, o objetivo do projeto é simplificar essa conexão.

Quer saber mais sobre o projeto? Veja o artigo escrito detalhando a minha experiência dos primeiros meses dentro do projeto:

Experiência dentro do projeto extensionista NÓS da UTFPR

Representação de uma pessoa anotanto em uma folha. Ilustrado pelo artista @LyaCalvet

É necessário resolver o problema?

Antes de tudo, é crucial analisar e verificar se o problema precisa ser resolvido com prioridade. Seguindo essa linha de raciocínio, uma das primeiras impressões que tive em relação ao fluxo de desenvolvimento anterior era de confusão. Isso ocorria porque, embora o fluxo se concentrasse nas ferramentas Git e GitHub, a maioria dos desenvolvedores construía o código para resolver uma tarefa e o enviava diretamente para a branch de desenvolvimento (development). No entanto, essa abordagem comprometia várias funcionalidades que as ferramentas oferecem.

Uma delas está relacionada à reversão de commits, podendo economizar muitas horas de dor de cabeça ao reverter códigos comprometidos ou inseridos de maneira incorreta. Por exemplo, um desenvolvedor A enviou quatro commits para a branch development. Logo após, o desenvolvedor B executou o comando para puxar o código da branch development e, em seguida, desenvolveu sua tarefa com base no que o desenvolvedor A havia enviado.

Aqui está o problema, pois abre brechas para cenários como:

• Desenvolvedor A enviou código quebrado, comprometendo o trabalho do desenvolvedor B.
• Desenvolvedor A enviou código funcional, mas com arquivos sensíveis, comprometendo o trabalho do desenvolvedor B.
• Desenvolvedor A enviou alterações locais (por exemplo, arquivos de configuração para adaptar ao gosto pessoal do desenvolvedor) para o repositório, comprometendo o trabalho do desenvolvedor B.”

Outra funcionalidade comprometida é o uso mais acentuado de branches. Uma branch, assim como o próprio site do Git, é uma maneira de divergir do código principal e modificar o contexto, concedendo total liberdade ao desenvolvedor para alterar o código sem comprometer o trabalho dos outros.

“A ramificação (branch) significa que você se desvia da linha principal de desenvolvimento e continua a trabalhar sem interferir nessa linha principal”
- Git, em https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

E ainda por cima, é acrescentado na mesma fonte o incentivo ao uso de branches para ramificar e mesclar os códigos.

“Git incentiva fluxos de trabalho que ramificam e mesclam com frequência, até mesmo várias vezes em um dia”
- Git, em https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

Conforme mencionado no site oficial da ferramenta, o uso de branches é incentivado em um fluxo de desenvolvimento, pois diferencia os contextos, auxiliando o desenvolvedor a se concentrar em uma tarefa por vez.

Desenho de uma pessoa comunicando através do computador. Ilustrado pelo artista @LyaCalvet

Gatilho para mudar

Dada a descrição dos problemas, é possível concluir que, dentro do contexto do projeto, onde é evidente a rotatividade dos membros da equipe e também a quantidade de membros, existe um gargalo no fluxo de desenvolvimento. No entanto, este não era considerado uma prioridade, uma vez que é apenas um gargalo e não uma parede ou obstáculo que impediria o fluxo de desenvolvimento de continuar funcionando (mesmo que de forma ineficiente). Portanto, a decisão de mudança ficou a cargo do líder da equipe, que deverá analisar a oportunidade de implementar mudanças.

Dito isso, a mudança ocorreu quando foi tomada a decisão de trocar o gerenciador de tarefas que a equipe de desenvolvimento utilizava, anteriormente o ClickUp. A mudança ocorreu devido ao fato de que a ferramenta possuía um foco “genérico” de gerenciamento de produto e, portanto, não oferecia ferramentas auxiliares para contextos de metodologia ágil, que era utilizada pela equipe.

Assim, a decisão foi tomada de mudar para o ZenHub, uma extensão da plataforma GitHub. Aproveitando o “embalo”, o fluxo de desenvolvimento foi modificado para solucionar os problemas mencionados anteriormente.

Desenho de um avião feito de papel. Ilustrado pelo artista @LyaCalvet

Mudanças

Uma das primeiras modificações foi o incentivo mais enfático ao uso de branches, seguindo a ideia de topic branches. Essa abordagem se baseia na analogia de que, para cada branch originada da branch development, está relacionada a uma tarefa

“Uma topic branch é uma branch de curta duração que é criada e utilizada para uma única tarefa específica ou trabalho relacionado.”
- Git, em https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

Representação da diferença de clareza entre o fluxo anterior (representado na direita) com o fluxo atual (representado na esquerda)

Tal mudança trouxe vantagens em comparação ao abandono dos topic branches, pois possibilita que os desenvolvedores enviem pequenos trechos de código (funcionando ou não) para o repositório principal. Isso proporciona a liberdade de trabalhar em pequenas partes em diferentes computadores, com uma área de trabalho rápida e flexível, sem depender de terceiros.

Outra alteração foi a adoção de issues e pull requests da plataforma GitHub para representar as tarefas da sprint da metodologia ágil. A primeira parte, referente às issues, surgiu como consequência do uso do ZenHub, que é uma extensão do GitHub e não possuía (agora há uma forma de tarefas apenas na plataforma) um gerenciador de tarefas integrado. A segunda parte, relacionada aos pull requests, representou um grande avanço para a equipe de desenvolvimento, pois permite a discussão, avaliação e controle da qualidade do software antes que seja implementado em ambientes próximos à produção.

Desenho de uma pessoa com uma lupa na mão. Ilustrado pelo artista @LyaCalvet

Então, vale a pena?

Após a alteração no ciclo de desenvolvimento, a equipe passou por uma fase de testes para verificar se as mudanças resultariam, no final do dia, em maior produtividade no fluxo de desenvolvimento. Os resultados finais foram positivos.

1. O uso de issues e pull requests abriu oportunidades para reforçar a qualidade de software no código antes que fossem implementadas em ambientes de desenvolvimento, ou até mesmo em produção. Além disso, proporcionou uma forma fácil de colaboração entre os membros, com commits alternados e discussões, tudo de forma assíncrona.
2. Com o fluxo inteiro na plataforma GitHub, surgiram oportunidades para introduzir ferramentas de pipelines CI (Continuous Integration, também conhecida como integração contínua) para verificar a qualidade do software automaticamente (por meio de um software de terceiros para a realização de testes). Até mesmo pipelines CD (Continuous Deployment, também conhecida como implantação contínua) foram implementados para o envio e construção do código em ambiente de produção automaticamente.
3. Por fim, ao utilizar as ferramentas do próprio GitHub, a plataforma que hospeda o repositório, traz vantagens indiretas relacionadas à documentação do projeto e dos códigos construídos. Ao incentivar o detalhamento técnico e estratégico (seja no âmbito dos negócios), pode ser utilizado como referência futura sobre certas decisões, aumentando a transparência das alterações e o entendimento dos demais membros em relação às mudanças.

Desenho de uma pessoa carregando várias caixas. Ilustrado pelo artista @LyaCalvet

Conclusão

Antes de tudo, é importante destacar alguns pontos, especialmente relacionados à organização do fluxo de desenvolvimento. Em equipes menores, o fluxo adotado e descrito neste artigo pode se tornar um gargalo, resultando em diferenças no resultado final. Portanto, vale ressaltar que este artigo foca em um âmbito e contexto específicos, e tais alterações não devem ser implementadas sem uma compreensão prévia da estrutura organizacional. Existem inúmeras variáveis a serem analisadas, principalmente no âmbito da equipe de desenvolvimento.