Dúvida sobre a melhor forma de trabalhar DEV Back e Front com Git

[leo-torrez]

Fala pessoal,
tranquilo?

Bom, gostaria de levantar alguns pontos para clarear um pouco mais minhas ideias e para isso gostaria da ajuda de vocês.

Na empresa em que trabalho, estamos querendo utilizar Git e fomos atrás de alguns fluxos conhecidos como o Gitflow. Estamos também tentando dividir o time em Front-end e Back-end e cada pessoa dev fica com sua responsabilidade.

Mas estamos com a seguinte situação(apenas um exemplo):

Dentro de nossa Story - Incluir lista de tarefas, possuímos duas tasks:

• Task para o Front
• Task para o Back

Qual desses dois casos abaixo vocês trabalhariam? (Ou qual a melhor forma de trabalhar na visão de vocês?)

Criariam uma única branch e tanto a pessoa FRONT como a pessoa BACK trabalhariam na mesma branch? E quando estivesse tudo completo jogaria para develop?

Criariam uma branch para o front e outra para o Back? Finalizando vocês jogariam para develop?

E outro ponto, qual o melhor momento para a pessoa TESTER realizar os devidos testes daquela funcionalidade? Na própria branch onde ela está sendo desenvolvida ou quando a funcionalidade já se encontra em Develop?

Obs: Até pesquisei aqui mesmo no fórum casos parecidos com Gitflow, mas o ponto aqui é mais como trabalhar a separação da equipe dentro do fluxo. Caso a Issue estiver repetida, foi mal XD

[viniciusvollrath]

Léo,

Nos projetos que participo e, também, pesquiso aqui no github vejo o seguinte:

• Cria uma organização
• Um repositório para cada time, exemplo: nomedoapp-frontend e nomedoapp-api ou backend
• Em projetos, na organização, cria um board global e "linka" (liga) todos os repositórios.

Dá para fazer muitas coisas legais com a api do github também.

[leo-torrez]

Opa, Vinicius.

Também gosto dessa separação quase que total, repositórios front-end & back-end separados. Mas, a pedido do cliente precisamos manter tudo no mesmo repositório.

Por isso da minha questão, pois precisamos manter tudo junto, mas essa parte de criação de branch para Front ou Back é nossa opção.

Usamos o VSTS (visualstudio.com) para gerenciamento de projetos.

[jbbn]

Olá @leo-torrez tudo tranquilo?

Posso te perguntar um coisa? (Duas né? rsrrs)
Quais tecnologias estão utilizando?

O mais comum hoje em dia - por N vantagens - seria ter 2 repositórios. Até por que as camadas front e back isoladas uma da outro só traz vantagem ("só" é modo de dizer, mas de fato evita vários problemas futuros e dá liberdade para ambas as partes crescerem sozinhas - e acredite, front e back possuem ciclos de vidas bem diferentes).

Como você já disse que o cliente quer tudo no mesmo repositório, não irei trabalhar com a ideia deles separados, ok?
Uma opção seria você ter, na raiz do projeto, duas pastas, algo como frontend e backend.

Perguntei da tecnologia que vocês estão utilizando, pois essa separação de camadas que citei acima (independente de ter um repositório ou dois) pode influenciar no como você vai trabalhar com o versionamento.

Vocês irão utilizar React, VueJS ou JavaScript puro, no frontend?
No backend seria PHP, NodeJS ou Go?

Pode ser algo que não citei, mas a grande questão é, o backend será uma API? Ou ele irá preparar a página com algum esquema de template?
Se for API, boa escolha :)
Se for template, o nível de acoplamento entre backend e frontend é mais alto e ideal seria que apenas um profissional desenvolvesse uma funcionalidade completa (entendendo de ambas as partes). Uma opção seria o backend preparar tudo e o frontend fazer a finalização - com seu conhecimento mais específico de browser e etc.

De modo geral, uma boa regra é mais ou menos a seguinte: um desenvolvimento do front não deve atrapalhar o desenvolvimento do back e vice-versa.
Como assim? Ninguém, de nenhum lado deveria subir código que quebra a aplicação. Pode parecer estranho, mas essa fórmula não falha.
Antes de subir uma porção de código para o branch principal, o desenvolvedor irá:

• puxar possíveis modificações deste branch para o dele (resolvendo conflitos neste momento);
• verificar se a aplicação está rodando e se nenhum bug foi gerado;
• e então fazer um merge para o branch principal.

Se algum bug que este desenvolvedor acabou não vendo subir para o branch principal, é dever dele corrigir o mais rápido possível.
Assim que ele subir este branch (sadio e sem falhas rsrs) os outros desenvolvedores poderão atualizar suas branchs com a branch principal, trazendo para si a funcionalidade desenvolvida pelo amigo :)
(Claro que não precisa TODO MUNDO fazer isso, só os que estiverem trabalhando nas mesmas funcionalidades)

Existem outras dicas também, como, por exemplo, que um branch de uma funcionalidade é bom quando é pontual e específico (quanto mais coisas um branch implementar antes de ir para o branch principal, mas chance de dar ruim).

Posso continuar te ajudando com algumas experiências que tive.
Mas não sei se você ainda precisa e se minhas dicas estão sendo úteis para o seu cenário.

Caso sim, compartilhe um pouco do seu projeto - o que não for informação sensível, claro - que tentarei continuar dividindo conhecimento.

Grande abraço e parabéns pelo dia do programador rsrs

[leo-torrez]

Opa @jbbn ,
tranquilo?

Valeu pela resposta.

Então, sobre as tecnologias, usaremos:

• Angular - Front
• C# - Back

As dicas estão sendo úteis sim.
Por enquanto, decidimos fazer uma única branch por Story e tanto dev Front e Back trabalhariam em uma única branch.

Aqui na empresa rolou alguns cenários:

1 - Ter uma única branch para tudo. No caso, ter develop e o master, mas todo mundo desenvolver no develop.
2 - Ter branchs sob demanda: No caso, uma branch por story ou até mesmo duas storys por branch (?)
3 - Master | Develop e criar uma branch para front e back trabalharam juntos.
4 - Master | Develop e o front e o Back criarem branchs diferentes e cada um trabalha na sua.

[jbbn]

Olá @leo-torrez
tranquilo e contigo?

Bom, com C# e Angular, nos casos que vi, o acoplamento é bem alto. Não vi um cenário aonde as camadas estavam bem separadas. (Mas também não trabalhei tanto com C#, então sou suspeito a opinar nisso).
Acredito que se vocês trabalharem com o Angular para criar componentes, teriam a vantagem de poder criar os componentes sem precisar do backend "funcionando" (localmente conseguiriam fazer tudo e depois seria só realizar a integração e testar - com componentes a vida fica bem mais fácil rs).

Misturando 2 cenários, eu votaria em algo entre o 2 e 3:
master, development e story-x (se o trabalho de back e front estiver bem acoplado, seria melhor utilizar uma branch só mesmo)

Agora se trabalharem com componentes poderiam ter também uma branch para estes.
master, development, story-x e component-x

Neste caso o backend pode trabalhar no story-x mesmo enquanto o front prepara o componente no branch component-x. Depois os 2 trabalham juntos no branch story-x para garantir que tudo funciona como deveria. Após isso é só mandar para development (aonde outros desenvolvimentos podem gerar conflitos - estes precisam ser resolvidos neste momento).

Eu até mudaria o nome desse branch de development para homol, pois alguém que cuida da regra de negócio, provavelmente irá testar o funcionamento do que foi desenvolvido neste ponto.
Após isso é só mandar o branch story-x para o master, gerar uma release e publicá-la ;)

---

Desculpe-me pela demora para responder.
Me conta, tá dando tudo certo por aí?
Acho que vocês já até resolveram essas questões, né? rs

Abraços!

[felipefialho]

@leo-torrez Resolveu?