As melhores práticas para lidar com projetos que dependem uns dos outros no Git?

6

Temos um produto que atualmente usamos o TFS como controle de origem para. Os recursos de ramificação / fusão do TFS parecem incrivelmente escassos e estamos migrando o projeto para o git, e quero aproveitar isso como uma oportunidade para limpar nossas práticas de controle de origem da melhor forma possível.

Atualmente, temos um único repositório no TFS, vamos chamá-lo de "root". na raiz, temos todos os nossos projetos separados. Temos duas versões do produto neste repositório, bem como um aplicativo front-end separado para a versão 2 do produto; Atualmente, o repositório se parece com algo assim:

<root repository>
|
|___Product_V1
|   |_[master branch]
|   |_[dev branch]
|   |_[any release candidate branches]
|
|___Product_V2
|   |_[master branch]
|   |_[dev branch]
|   |_[any release candidate branches]
|
|___Web-based_front-end_for_Product_V2
    |_[master branch]
    |_[dev branch]

Agora, ao migrar para o Git, não tenho certeza sobre qual seria a melhor prática para armazená-los. As minhas ideias atuais são as seguintes:

  • Ter um repositório separado para todos os projetos, um repositório para Product_V1 , um repositório para Product_V2 e um repositório para Web-based_front-end_for_Product_V2 - isso parece ruim porque o front-end baseado na web e o back-end serão separado
  • Tenha repositórios separados para Product_V1 e Product_V2 , tenha uma pasta "backend" e uma "frontend" sob o repositório Product_V2 e armazene os projetos lá, respectivamente. Essa parece ser a melhor opção, mas gostaria de saber de quaisquer problemas que possam surgir de pessoas que talvez tenham feito isso na prática?
  • continue como estávamos, tenha um único repositório com três diretórios, um para Product_V1 , um para Product_V2 e um para o front-end. Isso parece ser uma não-opção, Product_V1 e Product_V2 são totalmente não relacionados e quaisquer alterações em Product_V1 não têm efeito para Product_V2 e vice-versa. Eles são projetos totalmente independentes.

Quais são as melhores práticas para o Git que a maioria das pessoas seguiria nessa situação? Minha intuição é escolher a opção 2, mas não quero implementar algo agora apenas para atingir um armadilha óbvia 6 meses à frente eu não pensei no momento da implementação.

    
por James Trotter 15.11.2016 / 12:16
fonte

4 respostas

1

Já que você respondeu com mais informações, pessoalmente, eu configuraria como dois repositórios separados: um para cada V1 e um para V2 e seu front-end da Web, supondo que o front-end da Web seja altamente integrado e dependente (e precisa ser implantado junto com a V2). Se você tem alguma quantidade de abstração entre o produto em si e o aplicativo da web (uma API com versão, talvez?), Então você pode pensar em separar as duas bases de código.

Tudo isso é menos importante do que a sua equipe pensa sobre a estratégia de controle de origem / ramificação / fusão ... se você tem uma equipe além de si mesma, quero dizer: D. Fale com eles para encontrar uma boa direção também.

    
por 15.11.2016 / 20:57
fonte
0

Pessoalmente, não gosto da opção 3. Estou tentando fazer isso em um projeto e é uma dor de cabeça. Ao criar repositórios separados, você pode usar o recurso de submódulo do git para coletá-los em um único repositório de matéria. Isso também lhe dá a flexibilidade de trabalhar em qualquer repositório individual.

Quanto à escolha entre as opções 1 e 2, não tenho informações suficientes para formar uma opinião strong de uma forma ou de outra.

    
por 15.11.2016 / 22:03
fonte
0

Depende muito de como seus projetos são usados downstream do git - como eles são construídos, implantados, etc. Basicamente, seus processos automatizados ditarão o melhor método para a estrutura do repositório.

Por exemplo, se você estivesse usando, digamos, o Jenkins para construir seus projetos, a estrutura ideal do git seria usar um repositório, com várias ramificações (mestre, dev, release candidate). Você ainda teria cada projeto separado em sua própria pasta. Esta configuração permite que você tenha um único trabalho do Jenkins que pode construir tudo em seu repositório. Todos os três projetos, construídos com um clique. Isso não seria possível com três repositórios. Apenas três vezes mais trabalho quando você vai construir.

Se você não possui builds automatizados, basta usar qualquer estrutura que seja mais familiar para seus desenvolvedores e fazer a transição para git o mais fácil possível. Git é muito bom em fazer o trabalho, independentemente de como você configurou. Basta configurá-lo para melhor atender às suas necessidades. Os obstáculos que você provavelmente enfrentará provavelmente não estarão no seu repositório git ou em como você o estruturou.

As dependências entre seus projetos seriam resolvidas pelo seu sistema de compilação, não pelo git. O Git lida apenas com o código-fonte e o controle de versão, não com a ordem de construção ou com o gerenciamento de dependência. Portanto, a estrutura do repositório é irrelevante quando se trata de dependências.

Além disso, eu concordo com o guineveretoo - a estratégia de ramificação é muito importante. Ter uma estrutura git estranha equivale a um comando mais longo ou mais alguns passos para os desenvolvedores, mas é uma ação que nem sempre é repetida. Commits, e especialmente push, só devem acontecer quando uma mudança de código é construída e testada e pronta para ser usada. Do outro lado da moeda, ter uma estrutura que não corresponde à sua estratégia de ramificação faz com que seja um pesadelo para quase todos.

Para ver um exemplo de uma prática recomendada, a estratégia de ramificação testada e comprovada, consulte este guia .

    
por 16.11.2016 / 05:00
fonte
0

Em primeiro lugar, temos que levar em conta que o gerenciamento de projetos pode (e vai) condicionar a estratégia.

Dito isto, gostaria de ir para a 1ª opção .

Aqui estão minhas razões:

  • Eles são projetos completamente independentes. Como você já declarou.

  • Cada projeto pode ter um ALM diferente (controle de versão, CI, CD etc.). Isso também se aplica ao frontend.

    Versões de back-end e frontend podem ser gerenciadas de forma independente.

    Por exemplo, usamos o Gitlab e, até agora, sabemos que ele não nos permite criar tags / ramificações de conteúdo específico (pastas) que seja interrompido no mesmo repositório. Em outras palavras, obriga você a marcar / ramificar todo o repositório.

  • Cada projeto pode ser desenvolvido e gerenciado por diferentes equipes * (este é o meu caso, equipes especializadas: backend, frontend, UX, iOS, Android, CMS, etc.).

    Repositórios independentes facilitam os processos pull, commit, merge, push .

    Isso pode parecer irrelevante, mas não é especialmente se é a primeira vez que trabalha com o git.

Projeto de montagem _v2 - frontend

Ambos os projetos podem ser montados ultimamente. Por exemplo, durante CI ou via gerenciamento de dependências.

Eu não estou familiarizado com o NugetServer, mas parece que ele pode fazer o trabalho (como sugerido pelo @RubberDuck)

Desmontando o Projeto_v2 - frontend

Você pode decidir (por um bom motivo) remover o conteúdo estático (frontend) do back-end e veiculá-lo por meio de um servidor da Web (IIS). Por exemplo, digamos que você transformou o aplicativo MVC em uma API de middleware como REST.

Você já teria separado os dois projetos. Ter projetos desconectados permite entregas / implantações independentes. Isso é importante se você for para a nuvem. Pode poupar algumas implementações desnecessárias.

A chave é tratar o frontend como se fosse um aplicativo móvel (apenas mais um aplicativo cliente com seu próprio planejamento).

Resumindo, essa abordagem torna o ALM um pouco mais complicado (trabalho extra para todos), mas você ganha flexibilidade. É menos monolítico.

Observação: omiti referências ao project_v1. IMO é evidente que não tem nada a ver com os outros dois projetos. Motivo suficiente para mantê-lo separado.

    
por 15.11.2016 / 23:47
fonte