Depender do código fonte ou do binário?

Temos dois projetos internos, A e B, desenvolvidos por equipes diferentes, com B dependente de A. Como o código-fonte dos dois projetos é armazenado no git, incluí o projeto A como um submódulo no projeto B e configurei o sistema de compilação para construir ambos na ordem certa. Uma solução alternativa seria consumir A através de um gerenciador de repositório binário, como Artifactory ou Nexus.

Gostaria de saber sobre os prós e os contras de depender do código-fonte vs dependendo de artefatos binários. Quando um é melhor que o outro? Até agora, consegui apresentar os seguintes fatores, mas estou realmente interessado em ouvir outras opiniões.

Dependendo do código fonte é melhor

• se você não tiver um gerenciador de repositório binário
• se você precisar depender da versão de pré-lançamento de outro projeto
• se você precisar corrigir outro projeto
• porque é mais fácil procurar o código fonte da dependência no IDE

Dependendo dos binários, é melhor

• para minimizar o tempo de construção
• para evitar o incômodo de configurar o ambiente de construção de outro projeto

Eu sempre recomendaria dependências binárias sobre dependências de origem. A maioria dos profissionais que você lista para o código-fonte também pode ser facilmente incorporada às dependências binárias.

Primeiro, é muito rápido configurar um repositório Nexus em algum servidor local. Os benefícios de ter um repositório binário superam em muito o custo / esforço de instalação. Isso é quase um pré-requisito para o restante da minha resposta :)

Para versões de pré-lançamento, seus projetos devem implementar versões -SNAPSHOT no artefato. Pode haver uma distinção agradável e clara entre versões, como:

• projectA-3.2.0-SNAPSHOT : Desenvolvimento ativo, pode mudar a qualquer momento
• projectA-3.2.0-RC1 : Liberar candidato
• projectA-3.2.0 : Lançamento de produção

Todas essas versões podem ser armazenadas juntas no seu artefato. Seus projetos saberiam exatamente contra o que estão compilando.

Para patches, gité seu amigo. Bifurque o repositório e insira um número de versão do patch, como projectA-3.2.1-FOR_PROJ_B. Observe o .1 mostrando uma versão do patch e também o descritor. Isso também tornará mais fácil para o projeto recuperar essas alterações de volta ao mestre mais tarde.

Para o código-fonte, você pode configurar sua ferramenta de construção para gerar um "jar de origem" e implementá-lo ao lado do jar binário no artefato. A maioria dos IDEs pode procurar o nome do jar de origem e fazer o download automático da fonte para você.

Outro grande motivo para ficar longe do código-fonte é que você está vinculado ao sistema de construção, cadeia de ferramentas e dependências em tempo de compilação do Projeto A. Se você vir uma falha de construção no Projeto B, terá que investigar primeiro se o Projeto A ou O projeto B causou um erro. Se fosse o Projeto A, você rastreará as pessoas desse projeto para corrigir sua construção. Isso adiciona muita sobrecarga ao seu ciclo de construção.

Eu preferiria a dependência binária, porque quase nenhuma de suas considerações a favor de mim é sem crítica:

• se você não possui um gerenciador de repositório binário: tudo bem, mas não acho difícil estabelecer um. No nível mais básico, uma pasta compartilhada em que somente as pessoas responsáveis ​​por decidir qual versão usar podem escrever.

• se você precisar depender da versão de pré-lançamento de outro projeto: o metacubed já a cobriu. Com código-fonte ou dependências binárias, você deve manter uma versão bem estabelecida, mesmo que seja uma pré-versão. Obviamente, ao desenvolver um pré-lançamento, é provável que você precise mudar para uma versão atualizada, muitas vezes devido à resolução de erros.

• se você precisar corrigir outro projeto: você quer dizer que sua equipe vai corrigir o projeto feito de outra equipe na mesma casa? Eu diria que a estratégia mais sensata é dizer à outra equipe os problemas que você tem com o projeto deles.

• porque é mais fácil procurar o código-fonte da dependência no IDE: você não precisa bisbilhotar o funcionamento interno de suas dependências, porque isso significa:

  • o projeto A está mal documentado
  • seus codificadores terminarão usando "recursos não documentados" do projeto A que podem desaparecer sem aviso prévio a qualquer atualização.