Como posso defender o "gerenciamento de dependências"?

Atualmente, estou tentando defender a adoção do gerenciamento de dependências para compilações (ala Maven, Ivy, NuGet) e a criação de um repositório interno para módulos compartilhados, dos quais temos mais de uma dúzia de empresas. Quais são os principais pontos de venda dessa técnica de construção? Os que eu tenho até agora:

Facilita o processo de distribuição e importação de módulos compartilhados, especialmente atualizações de versão.
Requer que as dependências dos módulos compartilhados sejam documentadas com precisão.
Remove os módulos compartilhados do controle de origem, acelerando e simplificando os check-outs / check-ins _{(quando você tem aplicativos com mais de 20 bibliotecas, esse é um fator real)} .
Permite mais controle ou conscientização sobre quais bibliotecas de terceiros são usadas em sua organização.

Faltam alguns pontos de venda? Existem estudos ou artigos que fornecem métricas de melhoria?

dependency-management

— Cruz
fonte

Eu acho que você acertou em cheio.

— Mike Partridge #

Eu nunca voltarei as muitas horas da minha vida desperdiçadas com configurações quebradas do Maven. Eu me convenci de que, independentemente das boas intenções, em uma grande corporação, ela acabará se tornando uma bagunça não mantida que suga a vida de você até que você seja uma concha oca.

— MrFox

@suslik Quer saber o que é uma configuração "quebrada do Maven"?

— Andrew T Finnell

@AndrewFinnell Digamos que há 5 grupos trabalhando em projetos que você precisa para compilar sua compilação e, devido à falta de coordenação, todos acabam dependendo de versões diferentes das bibliotecas. Acontece que um dos projetos não deveria ser "lançado" ainda, mas (ninguém disse ao maven!) Você tem uma dependência que precisa satisfazer. Isso não deveria acontecer, mas a resolução automática facilita demais. Se todos tivessem um diretório / libs para manter no svn, forçaria as pessoas a parar e fazer perguntas antes que as coisas saíssem do controle.

— MrFox

@ MrFox Isso é realmente por causa da falta de coordenação, não da resolução de dependência do Maven. Eu experimentei as mesmas situações e não sou fã do Maven, mas acho que as ferramentas não devem resolver problemas relacionados ao ser humano, como lançamentos prematuros, falta de comunicação, falta de testes, manutenção deficiente etc.

— scriptin

Respostas:

Não tenho 100% de certeza dos aspectos positivos. Aqui estão alguns negativos

Você acaba adicionando dependências a servidores / pontos de extremidade de terceiros que podem não ser estáveis.

Já tive com o bower que o repositório de algumas dependências foi excluído ou movido. Assim, um novo desenvolvedor aparece, clona meu repositório, digita bower installe obtém erros para repositórios não acessíveis. Se, em vez disso, eu fiz o check-in do código de terceiros no meu repositório, esse problema desaparece.

Isso é resolvido como o OP sugere, se você estiver obtendo deps de cópias mantidas em um servidor que você executa.
Mais difícil para noobs.

Trabalho com estudantes de arte com muito pouca experiência em linha de comando. Eles fazem arte com Processing, arduino, Unity3D e se dão bem com muito pouco conhecimento técnico. Eles queriam usar algum HTML5 / JavaScript que escrevi. Passos por causa do pavilhão
1. Faça o download do Zip do repositório no github (observe que está à direita de todos os repositórios no github. Porque eles não conhecem o git)
2. Faça o download e instale o nó (para que possamos executar o npm para instalar o bower)
3. Instale git ou msysgit (porque o bower exige e não está instalado nas máquinas de muitos alunos)
4. Instalar o caramanchão ( npm install -g bower)
5. bower install (finalmente para obter nossas dependências)
As etapas 2 a 5 podem ser excluídas se apenas fizermos o check-in dos arquivos no repositório do github. Esses passos provavelmente parecem super fáceis para você e para mim. Para os alunos, eles eram muito confusos e queriam saber para que todos os passos, onde e para que servem, poderiam ser um bom aprendizado, mas possivelmente inteiramente ortogonais ao tópico da classe e, provavelmente, rapidamente esquecidos.
Adiciona outro passo ao puxar.

Já aconteceu muitas vezes que eu faço git pull origin mastere testo meu código, e leva de 5 a 10 minutos para lembrar que eu precisava digitar bower install para obter os deps mais recentes. Tenho certeza que isso é facilmente resolvido com um gancho de script pull.
Isso torna o git mais difícil de ramificar

Se dois galhos têm deps diferentes, você meio que está ferrado. Suponho que você possa digitar bower installdepois de cada git checkout. Tanta velocidade.

Quanto aos seus pontos positivos, acho que existem contra exemplos para cada um desses

Facilita o processo de distribuição e importação de módulos compartilhados, especialmente atualizações de versão.

vs o que? Certamente não é mais fácil de distribuir. Puxar um repo em vez de 20 não é mais fácil e é mais provável que falhe. Veja o nº 1 acima

Remove os módulos compartilhados do controle de origem, acelerando e simplificando os check-outs / check-ins (quando você tem aplicativos com mais de 20 bibliotecas, esse é um fator real).

Por outro lado, significa que você depende de outros para correções. Ou seja, se seus departamentos estão obtendo de uma fonte de terceiros e você precisa de um bug corrigido, você deve esperar que eles apliquem seu patch. Pior, você provavelmente não pode apenas pegar a versão que deseja, mais o seu patch; você deve escolher a versão mais recente, que pode não ser compatível com o seu projeto.

Você pode resolver isso clonando os repositórios separadamente e, em seguida, aponte os deps do projeto para suas cópias. Em seguida, você aplica as correções em suas cópias. Claro que você também pode fazer isso se apenas copiar a fonte no seu repositório

Permite mais controle ou conscientização sobre quais bibliotecas de terceiros são usadas em sua organização.

Isso parece discutível. Apenas exija que os desenvolvedores coloquem as bibliotecas de terceiros em sua própria pasta <ProjectRoot>/3rdparty/<nameOfDep>. É fácil ver quais bibliotecas de terceiros são usadas.

Não estou dizendo que não há pontos positivos. A última equipe em que participei tinha> 100 de terceiros. Só estou apontando que nem tudo são rosas. Estou avaliando se devo me livrar do caramanchão para minhas necessidades, por exemplo.

— gman
fonte

Uau, muitos votos negativos e nenhuma justificativa para eles. Bom trabalho! :(

— gman

Eu nunca usei o bower, mas a necessidade de installcada vez que você faz o checkout parece uma falha de design. Ele deve verificar sua configuração ao criar um projeto: se houver alterações, ele deverá ser reconstruído do zero. Além disso, a movimentação de repositórios é irrelevante para o Maven, pois extrai artefatos do repositório Maven, que armazena artefatos, não os repositórios reais com código. Você só pode alterar artifactIde groupIdna próxima versão do seu artefato se o publicar no repositório Maven. Portanto, seus pontos 1 e 4 são principalmente irrelevantes para o Maven, em particular. # 3 pode ser substituído por mvn clean(às vezes)

— scriptin

Embora seja verdade, o número 2 não é uma desvantagem - é uma troca. Claro, você tem que aprender suas ferramentas! Por exemplo, o Git é muito difícil de entender, mas não vou desistir por causa de dem noobs.

— Script #

Dê uma olhada no The Twelve Factor App

Em particular, leia sobre o que eles têm a dizer sobre dependências . Você notará que um bom design fornece um mecanismo declarativo para localizar dependências; em Java, isso geralmente é realizado através do Maven. Ivy e NuGet funcionam bem, mas Maven é atualmente o líder em campo e Ivy é decididamente um trabalho árduo.

Se você aderir ao processo de liberação do Maven (desenvolver snapshots até que uma liberação formal esteja pronta, nunca tentar sobrescrever uma liberação anterior, use um gerenciador de repositório adequado como o Nexus ou o Artifactory), então você deve ter um processo de compilação que seja bem-sucedido.

Depois de ter um sólido processo declarativo de construção, ele abre as portas para outras boas práticas, como Integração Contínua com Jenkins , Análise Contínua de Código com Sonar e você se encontrará à procura de uma melhor estratégia de ramificação de controle de versão usando o git .

Cada uma das opções acima baseia-se no núcleo que é o Maven. Hoje em dia, é praticamente uma decisão fácil.

— Gary Rowe
fonte

Eu olhei para o The Twelve Factor App, mas é extremamente controverso e apenas um pouco é relevante. Também pressionar Maven não me ajuda a explicar por que precisamos de injeção de dependência. No geral, essa resposta não me ajuda a vender a Injeção de Dependência, apenas me diz muitas coisas que preciso fazer no meu processo de compilação.

— 12483 Ross C.

A Injeção de Dependência (o padrão de design) não é Gerenciamento de Dependência (o padrão de construção). Você já cobriu todos os aspectos mais importantes da sua pergunta. Se a sua equipe ainda precisar convencer depois de ouvir isso, então ver o que o Gerenciamento de Dependências levará deve ser o convencente final.

— Gary Rowe

E o item nº 1 em nossa lista dos 10 melhores é ...

(rolo de tambor)

Todo desenvolvedor cria exatamente as mesmas versões de todas as dependências, para que você nunca precise se perguntar o que implementar na produção.

— Ross Patterson
fonte

Como isso é diferente de verificar as dependências? De fato, se você não verificar as dependências, corre o risco de terceiros quebrar sua distribuição. Isso aconteceu mais de uma vez, em que alguns dep de bower apontam para um repo que alguém excluiu ou renomeou. Se eu tivesse copiado a fonte em nosso repositório, esse problema desapareceria.

— gman