Benchmarking | Git Workflow

[carloshenriqueribeiro]

Galera, blz ?

Passei pelas issues sobre Git Workflow e encontrei algumas que já falaram sobre o assunto mas... ou estavam em 2016 ou eram + Help tentando ajudar um colega a resolver um problema específico.

issues: #351 e #120.
existem outras além destas duas.

O ponto é que achei válido levantarmos este assunto novamente agora em 2018.

Iniciei um projeto do zero a pouco tempo e estou usando git flow com as configs default mas estou pensando em algumas adaptações para otimizar o flow.

Como estamos fazendo ?

FASE 01 - Chuva de Features

1)Os devs começam os trabalhos

git flow feature start XPTO

e trabalham na feature localmente durante um 1 ou + dias.

2)Ao terminarem a Feature

git flow feature publish XPTO
git flow feature finish XPTO

Criar PR no VSTS

• para mandar a Feature para o remoto.
• finalizar localmente a Feature.
• enviar uma PR através do VSTS para develop.

---

FASE 02 - Montagem do Ambiente Test

definição de responsabilidade/papel : O Dev responsável por este projeto é quem irá controlar o que entra pra branch develop e o que vai para realease .

3)O Dev repo, analisa as PRs na branch develop , seguindo o padrão, de aprovar, reprovar ou abandonar uma ou + PR .

Feito isso, subimos para o ambiente de homologação as features (usamos o Build do VSTS com a branch develop como padrão).

FASE 03 - Preparando para Produção

após a validação dos testes, preparamos a realease. Momento para tirar as features não aprovadas pelos testes. Aproveitamos para aplicar o Git rebase e dar aquela organizada básica nos commits e assim criarmos um histórico limpo e facil de entender quando for para master

4)Dev repo irá gerar a release

git pull origin master
git pull origin develop
git flow release start 3.2.0

Pronto! Agora tá liberado fazer um rebase e deixar tudo clean. Terminou os ajustes ?

git flow release finish 3.2.0 -m 'aqui vai a msg'

Bom.. tudo organizado localmente ? Beleza. Então hora de dar um push.

git push origin develop

Ou ou ou ou... Pq develop ? Simples. Não permitimos push direto na master, tem que vir por PR .

Então abrimos o portal do VSTS, criamos a PR e efetuamos o Merge com a branch master .

FASE 04 - Subida para Produção

5)Vamos no build do VSTS e geramos o deploy da release baseado na branch master .

Build com sucesso ?

Vamos dar aquela última conferida para ver se não quebramos nada em produção.

1. Acesso com user fake;
2. Validamos os principais fluxos do portal;
3. Damos uma passada nas Features e finished .

---

Ambiente :
OS que trabalhamos : Windows
Adaptações : costumo criar alias para alguns comandos, principalmente para facilitar a navegação entre os repos.
Terminal : Cmder 😍

Pontos de atenção:

• Acho a documentação do Git flow meio largadona, sem atualizações da doc o que é meio ruim.
• Existem alguns cenários que talvez eu terei que fazer uma adaptação no workflow para atender o negócio. Sendo o primeiro:

1. Precisamos de 3 ambientes [Dev (cliente não tem acesso), Hml (pro cliente fazer testes) e produção.].
2. Reduzir o risco dos devs trabalharem com branchs develop e master desatualizadas.
3. Trazer a PR para o CLI;

---

Como funciona aí no seu trampo ?

Tem alguma sugestão para o nosso workflow ?

[carloshenriqueribeiro]

@lfeh seria legal ter uma label de banchmarking.