Workflow de Git para equipes com entrega contínua

[fxcosta]

Boa noite!

Adotamos git na minha equipe tem pouco tempo e até então como cada um tem trabalhado em coisas isoladas, nunca tinhamos tido problemas quanto a workflow. Agora, temos vários desenvolvedores trabalhando em cima de tarefas correlatas. Vou explicar o cenário atual e apontar os problemas:

Temos adotado algumas coisas do gitflow, então temos branches como master (reflete a produção) e develop e usamos branches secundárias pra features e bugfixes. O passo a passo é:

• Cria uma branch secundária a partir de develop, ex, feature/algumacoisa
• Desenvolve e quando finalizar, dava push dessa branch pra origin
• Abria um pull-request dessa branch pra develop
• Eu fazia code review, aceitava e o código era mesclado em develop
• Nos dias de entrega eu mesmo abria uma PR de develop pra master

O problema é que agora temos um terceiro ambiente, de homologação, que chamamos de homolog (podem chamar de staging, testing, etc). Nesse ambiente a ideia é que uma pessoa de testes e qualidade avalie antes de ser enviado pra produção.

Os problemas surgiram quando 12 tarefas foram mescladas em develop, eu simplesmente joguei de develop pra homolog e na avaliação somente algumas tarefas precisavam ser entregues em produção por alguns motivos.

Problema 1 - Como eu poderia ter estruturado de forma a conseguir selecionar melhor o que deve ser enviado pra produção ou não?

Com esse problema, começamos a estudar melhor o gitflow e entendemos que talvez tivessemos que começar a usar "release" branches só que ainda assim não conseguimos entender em que momento ou de que forma isso ajudaria tanto. Se bem entendemos, pelo gitflow, os release branches serviriam mais como formas de "registrar" aqueles marcos no sistema, não?!

Problema 2 - Se formos usar gitflow a vera, o dev coda, mescla em develop e sobe pra origin. Quem abre o PR e de onde pra onde? Um único PR sempre (develop > homologação)?

Problema 3 - E se o dev A finaliza 3 tarefas mas somente as 2 últimas tarefas devem ser aceitas ou passaram no teste, como poderíamos "coletar" somente o necessário se teoricamente ele desenvolveu de forma que uma depende da outra?

Gostaria de finalizar essa dissertação de mestrado com a dúvida de como vocês trabalham, em ambientes com muita gente no mesmo produto, de forma que a gente não perca 1 dia inteiro simplesmente pra lançar umas tarefas pra produção. Obrigado!!

[carloshenriqueribeiro]

Dúvida: você deleta as Features no remote (geralmente com o nome de "origin") depois do Merge ?

[fxcosta]

@carloshenriqueribeiro sim, tenho deletado do origin (usamos gitlab) depois do merge.

[carloshenriqueribeiro]

Você poderia fazer PR direto na master só das Features aprovadas e só neste momento deletar a branch da feature.

[carloshenriqueribeiro]

Como eu Solucionaria
Problema 2:
Dev - abre PR da feature em remote para develop
Tester - abre PR para Hml, sinalizando a aprovação;
Responsável do projeto - aprovada as PRs de develop, hml e monta a versão de master.

[carloshenriqueribeiro]

Problema 3:
Se elas dependem uma da outra então não deveria passar no teste de integração (manual ou automático).

[ninetails]

Já usei um gitflow meio que manual (digo, sem plugin) onde eu trabalhava e funcionava bem.

Desenvolvimento

Antes de tudo, a gente travava a develop para que ninguém possa subir código nela.

Os devs irão subir a release, e dela criar um pull request para a develop onde o pessoal (ou mesmo você) possa fazer o code review.

Feito isso, mesclado na develop, vc terá várias features se acumulando. Se seu mundo for ideal, eu aconselho fazer um githook para toda a vez que mesclarem para a develop (somente via pull request), suba para um ambiente de desenvolvimento (develop ou staging).

Homologação

Da develop, crie uma branch de release. A gente compilava as features em um arquivo de Release Notes. Também davamos uma versão para ela de release (Semantic versioning). Criado essa branch de release, suba para um ambiente de homologação (que não é o develop/staging). Pode dar o nome de homolog, QA etc. Lembrando que o nome dos ambientes são o de menos, mas o ideal é que esses ambientes sejam acessíveis somente internamente, na rede ou atrás de uma autenticação onde restrinja acessos externos. Em cada ambiente também é ideal se ter um banco de dados próprio para não "sujar" seus dados de produção.

Também tenha em mente pedir aos desenvolvedores fazer o código de modo que seja fácil fazer mock de requisições e testes automatizados e2e (end-to-end, não são os unitários nem de integração, são aqueles que testam usando um browser para interagir na tela) pq aqui além do QA revisar, seria bom também deixar rodando algum automatizador de testes e2e.

Produção

Testado (homologado) por QA e por e2e, mesclar na master, criar a tag com a versão dada na homologação e correr pro abraço :D (claro, estou simplificando, daqui pra frente o trabalho não é mais de desenvolvimento mas ver ferramentas que ficam monitorando uso em prod)

Só lembrar também que tem os fluxos de exceção (bugfix, hotfix)... Mas se tiver tudo com integração contínua, seus steps manuais seriam basicamente code review, criar a branch de release e mesclar na master, com o restante tudo automatizado.

[fxcosta]

@ninetails @carloshenriqueribeiro obrigado!! com a dica de vocês e mais alguma análise percebi que esse tipo de coisa pode ser um "depende". Com essas dicas consegui desenhar uma arquitetura que talvez nos ajude. Vamos testar e caso funcione postarei um artigo pra registrar. Valeu!!

[mahenrique94]

Acho que adicionando as releases branchs para seu workflow deveria resolver seu problema de homologação.

[fxcosta]

@mahenrique94 a dúvida era justamente como adaptar essa questão das release branches com um servidor de homologação e depois se for o caso alterar essa branch removendo commits ou até mesmo feature branches.

[mahenrique94]

Acho que você poderia montar um CI e CD da branch feature para o servidor de homolog, depois que tudo estiver validado e homologado, faça o merge para a branch de develop e master (onde vai ter um CI e CD para produção).

[napalmdev]

Na empresa onde eu trabalho utilizamos o Gitflow manualmente tbm(sem plugin), e o fluxo é basicamente utilizando release branches, tipo:

• Desenvolvemos local(pode ser em uma branch especifca Ex: fb_nome_da_feature) e abrimos PR pra development, aqui já vem a parte de code review e como utilizamos o bitbucket pipelines já é rodado a suite de testes e afins, então se quebrar todo mundo ja fica sabendo.

• Feito o merge em development, fazemos o push pra release-beanch que segue o semver, o pipeline das releases branches já está configurado pra tbm rodar os testes, efetuar o build e em seguida fazer o deploy pra homologa.

• Quando for fechar pra produção, olhamos qual release-branch está ativa e criamos uma tag com a mesma versão e subimos na master que já está tbm configurada pra fazer o deploy.

É mais ou menos nesse eskema :D, mas na mminha opinião o fator principal pra um workflow é a comunicação entre a equipe, aqui sempre que alguem vai enviar algo pra homologa ou prod, já conversamos no slack e avisamos que vamos subir x release, assim todos sabem que tem alguem trabalhando com homologa ou prod naquele momento, isso por si só já salva de muita dor de cabeça ueheuehue. espero ter ajudado em algo.

[phsantiago]

Nos lugares que já trabalhei vi muitas variações de uso do git, a melhor que acho hoje é:

• PRs apontando para master, onde se roda toda parte de CI e QA.
• Necessidade de dois approves para merge.
• Tags com SEMVER logo após cada merge na master.

There are beauty in simplicity

[fxcosta]

@napalmdev estamos testando justamente algo similar a isso nesse momento só que depois de feito merge em develop, é feito push e deploy pra homolog para testes. O que tenho testado pra ver se funciona é, na sexta quando o release vai ser lançado, eu crio uma branch de release juntando todas as branches que "passaram" tanto em testes quando em qualidade. Aí de release mandamos pra master.

Nessa última sexta-feira encontrei alguns problemas ainda com essa abordagem...

@phsantiago eu vi alguns workflows que trabalham em cima da master mas então o meu ambiente de homologação teria uma cópia de master ou como funcionaria?

[napalmdev]

@fxcosta, legal cara, depois passa um feedback do q vc achou dessa abordagem e se funcionou legal pra vcs

[phsantiago]

eu vi alguns workflows que trabalham em cima da master mas então o meu ambiente de homologação teria uma cópia de master ou como funcionaria?

@fxcosta Sempre que você fizer merge de um pr, você cria uma Release Candidate. O código dessa release vai para homolog, se der certo você cria a Release msm e coloca em prod.

[bmsrox]

@fxcosta conseguiu?

[fxcosta]

@bmsrox temos usado mais o esquema do @ninetails e tem funcionado bem, porém, ainda acontecem alguns problemas que fazem com que por vezes, tenhamos que antecipar ou adiar uma release pra produção.

Com uma equipe agora maior no projeto, pra evitar burocracia e impedimentos, toda vez que o developer sente-se confiavel com uma branch (feature/bugfix), ele manda pra develop. Antes isso era enviado para uma PR pra code review mas acabava impedindo demais o time já que eu quem fazia o code review.

Como develop agora tem tudo "atualizado", sempre subimos develop pra homologação para testes de cliente e etc. Se algo que está em develop não deve ser enviado pra produção, tenho feito manualmente a coleta das "branches" que devem ser enviadas numa branch de release usando semver.

Se tudo em homolog passa, a release branch vem de homolog. Fazemos merge da release branch para master e então as coisas estão "entregues".

Podem perceber várias brechas nesse esquema mas ainda temos testado muita coisa e aprendido com o tempo. Um grande problema nosso é que pra esse projeto em específico, temos lidado com um codebase legado sem testes então a desconfiança com o código de homolog é enorme. Projetos legados custam muito, justamente porque todo o processo de deploy, testes, análises, é bem manual.

Resumindo, acredito que ainda não conseguimos.

[ricardosoareslacerda]

eu passo pelo mesmo problema seu, é igualzinho, mas aqui é monolito e jenkis de ci mas só isso ... os nomes aqui são trocados, nossa master é de dev rs ... e temos um branch de hml (work) onde tiramos as tags e colocamos em produção ...
Estamos também estudando modelos, mas o que nos ajudou muito foi atualizar uma branch de produção (prod) assim que é feito o deploy no ambiente produtivo (aplicada a gmud) .. e cada feature nova se baseia de prod ... assim ela não se "contamina" com outra feature não homologada

[ricardosoareslacerda]

tenho tentado aplicar a cultura do gitflow mas o pessoal é muito difícil de padronização ... preferem deixar a manutenção pra depois .. .venho tentando mudar isso

[bmsrox]

Estou nesta mesma situação.

[ninetails]

@fxcosta daria para mitigar a falta de teste tendo um bom code review e colocando testes e2e automatizados, testando na homologação... não é o melhor dos mundos, mas talvez traria uma maior confiança... ou talvez deixar umas tasks em toda sprint para refatorar "o que der" mas aos poucos

[yvesguilherme]

Acho que isso aqui seria o ideal para ti...

https://nvie.com/posts/a-successful-git-branching-model/