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


9

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

1
Na minha experiência, a possibilidade de corrigir outro projeto é fundamental. Às vezes, os patches não precisam ser puxados de volta para o mestre (extensões / modificações específicas do projeto). Nesses casos, você precisará configurar um ambiente de construção para o projeto dependente de qualquer maneira. Então, usamos a dependência do código fonte. Mas, é claro, isso depende dos seus processos / arquitetura.
proskor

Respostas:


5

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.


Justo, exceto pelo último ponto. Um submódulo git implica que você depende de uma versão exata de outro projeto. Como as dependências nunca são atualizadas juntamente com outras alterações, é sempre óbvio se as alterações no projeto A ou no projeto B causaram estragos. Obrigado pela sua resposta!
Mkalkov 9/07

1

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.

1
Corrigindo projetos internos: bem, é uma questão de planejamento. No nosso caso, "internamente" significa a mesma organização, mas departamentos diferentes e localização geográfica diferente. Imagine o projeto A devs apresentando um novo recurso (de buggy). Nós (desenvolvedores do projeto B) planejamos uma nova versão que depende desse recurso e, no meio do processo, descobrimos um bug nele. Nossas opções são: (a) corrigir o bug, fazer o lançamento no prazo e enviar o patch a montante, ou (b) reportar um bug a montante, esperar até que o conserte no próximo sprint e faça nosso release um sprint atrasado. Às vezes a opção b é aceitável, às vezes não.
Mkalkov 9/07

Também me pego pesquisando o código-fonte do JDK com bastante frequência porque isso me torna um melhor codificador e porque às vezes nem a documentação de classe mundial é suficiente. No entanto, isso não significa que eu uso recursos JDK não documentados. A mesma lógica se aplica ao código fonte da dependência. Eu concordo que isso deixa espaço para uso indevido. Obrigado por seus outros pontos!
Mkalkov 9/07

Em relação ao seu primeiro comentário, parece que seu sistema pode levar a um cenário em que a equipe A lança o "Projeto A 2014 v1" e a equipe B lança o "Projeto B 2014 v1" que inclui um "Projeto A 2014 v1" que não é exatamente o mesmo de equipa Um lançado ...
SJuan76

É mais como "a equipe A lança o projeto A-1.2.3 e a equipe B lança o projeto B-4.5.6, que inclui o projeto A-1.2.3-patch1".
Mkalkov 9/07
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.