Processos de Desenvolvimento podem te salvar!

Vamos além do gitflow entender o melhor fluxo pro seu time

Um dos maiores aprendizados que consigo tirar depois de alguns anos na área é:

Como processos bem estruturados utilizando Gitlfow podem salvar muito retrabalho que a gente tem.

Quero trazer pra você hoje uma sugestão compilada complicada de alguns casos aprendidos ao longo da minha carreira, que é sobre processo de desenvolvimento.

Deve ser sabido por você que já trabalha com tecnologia em como ter ambientes de desenvolvimento, staging e produção equalizados pode nos ajudar a entregar nossas demandas com mais certeza de qualidade, e evitar retrabalho com cherry-picks e equalização de branchs né?

MAS, como garantir um processo que domine esse fluxo e se mantenha sempre atualizado?

Fluxo estruturado desde a definição até o deploy

Nosso processo começa claramente definido desde o planejamento da tarefa até a sua disponibilização em produção. O fluxo segue etapas bem estabelecidas:

1. Definição clara das tarefas

A gente subestima muito definição de pronto pra desenvolvimento e pronto pra produção né?

Ta aí uma das paradas que eu mais gosto: DoR, DoD - aprenda com seu time a ter uma definição de pronto pra começar a desenvolver e pronto concluído.

A tarefa precisa estar muito bem especificada antes do início da codificação, lá no refinamento técnico ou na planning precisam estar CLAROS.

Clareza na descrição evita retrabalho e alinhamento incorreto da solução.

Coloquei como uma das primeiras etapas por considerar essencial todos do time sendo devs ou não estarem alinhados das entregas

2. Branches específicas para features

Cada tarefa ganha uma branch específica, nomeada com clareza, como feature/update-promo. Trabalhar com branches isoladas reduz interferências e facilita a revisão posterior.

Além disso, commits atômicos são essenciais para garantir uma boa rastreabilidade das mudanças realizadas.

Existem inúmeras referências de como aplicar git flow por aqui, o desenho que eu mais curto que acredito fazer bastante sentido com o que eu estou escrevendo seria esse:

Aliás a fonte dessa imagem é um desenho oriundo de um artigo muito bom de um fórum de uma comunidade chamado IzaTec, vale a pena leitura → https://iza.tec.br/content/community/ferramentas/git-flow

3. Testes contínuos

Cada alteração é testada localmente antes de avançar para outros ambientes.

Os testes unitários são mandatórios, garantindo que funcionalidades básicas estejam preservadas desde cedo.

4. Revisão rigorosa de código (Code Review)

Antes do merge para a branch development, cada Merge Request (MR) é revisado detalhadamente pela equipe.

5. Ambiente de Desenvolvimento e QA

A validação em ambiente DEV detectam rapidamente problemas não identificados localmente.

Após essa etapa, a tarefa pode ser submetida ao QA, que realiza testes detalhados nas APIs e nas integrações envolvidas, garantindo robustez da solução. Ou pode ser a própria pessoa que desenvolveu a alteração testar e coletar evidências ou possíveis ajustes.

6. Validação em Staging ou Homologação

Antes do deploy em produção, homologação valida as funcionalidades em contexto próximo ao ambiente produtivo, incluindo a verificação rigorosa de integrações, desempenho e requisitos funcionais.

7. Revisão formal e padrozinada das mudanças

Aqui num time na qual os devs não são fullstack faz sentido repetir esse fluxo pra API que estar pronto poder ser implementada com o time de frontend, caso não seja um time fullstakc e toda a funcionalidade esteja pronto num ambiente para produção, aqui faz sentido ter uma validação extra com time de produto.

A empresa pode ter aqui uma GMUD ou não, mas alinhar as entregas e releases que vão subir pra produção é extremamente importante.

No final o fluxo ficaria algo mais ou menos assim:

PLUS Padrões de Merge Requests

Um ponto chave na aplicação eficiente do Gitflow são os padrões definidos para MRs, que usam templates configurados previamente no GitLab. Existem templates distintos para cada tipo de alteração:

• Default para novas funcionalidades ou correções não críticas.

• Hotfix para correções emergenciais em produção.

• Release para deploys entre ambientes.

Cada template já vem pré-preenchido, facilitando o entendimento e garantindo consistência entre as revisões.

Recomendações adicionais essenciais:

• Clareza e objetividade: garantir descrições claras em todas as MRs.

• EVIDÊNCIAS DAS MUDANÇAS: Aqui até pra ter documentado é legal ter prints ou vídeos da tela funcionando

• Foco nas mudanças: manter uma mudança por MR para simplificar revisões.

• Checklist completo: sempre garantir que todos os itens do checklist sejam validados antes da revisão.

Conclusão

No fim é tudo uma grande experimentação, isso pode ou não funcionar pro seu time!

MAS arrisco dizer que grande parte dos casos funciona, ter processos é fundamental pra que evite trabalhos invisiveis ou retrabalho dentro de uma demanda, seja você back, front ou até mesmo devops.

Me conta nos comentários como funciona o processo de desenvolvimento do seu time, vamos trocar algumas figurinhas 🤩