我该如何为“依赖管理”辩护？

我目前正在尝试为构建（ala Maven，Ivy，NuGet）采用依赖管理，并为共享模块创建内部存储库，我们在十几个企业范围内。这种构建技术的主要卖点是什么？到目前为止，我有：

简化了分发和导入共享模块的过程，尤其是版本升级。
要求精确记录共享模块的依赖性。
从源代码管理中删除共享模块，加快并简化检出/检入_{（当您的应用程序具有20多个库时，这是一个实际因素）}。
使您可以更好地控制或了解组织中使用了哪些第三方库。

我有没有卖点？是否有研究或文章提供改进指标？

dependency-management

— 罗斯
source

我认为您已经钉牢了。

— 迈克·帕特里奇

我永远都不会浪费大量的时间在破碎的Maven设置上。我已经确信，不管有什么好意，在一个大型公司中，它最终都将变成一个无法维持的混乱局面，直到你是空心的壳时，才将你的生命吸走。

— MrFox 2012年

@suslik Care会详细说明什么是“破碎的Maven”设置？

— Andrew T Finnell，2012年

@AndrewFinnell说有5个小组在处理项目，您需要引入这些项目来编译构建，并且由于协调性差，每个人最终都依赖于不同版本的库。事实证明，其中一个项目不是要“发布”的，但是（没有人告诉过Maven！）您需要满足一个依赖项。这不是“应该”发生的，但是自动分辨率使它变得太容易了。如果每个人都有一个/ libs目录来维护svn，它将迫使人们停下来并在问题失控之前提出问题。

— MrFox 2012年

@MrFox确实是因为协调不力，而不是Maven依赖关系解析。我已经经历了同样的情况，我不是的Maven的粉丝，但我认为工具不应该像解决过早释放人类有关的问题，缺乏沟通，缺乏测试，保养不善等

— scriptin

Answers:

我不能肯定100％的积极性。这是一些负面因素

您通常最终会向不稳定的第三方服务器/端点添加依赖项。

我曾在凉亭上发生过某些依赖项的回购被删除或移动的情况。因此，一个新的开发人员出现了，克隆了我的仓库，输入了类型 bower install并得到了无法访问的仓库错误。相反，如果我将第3方代码签入我的仓库中，该问题就会消失。

就像OP所建议的，如果您要从运行的服务器上保留的副本中提取dep，则可以解决此问题。
对于菜鸟来说更难。

我与很少有命令行经验的美术专业学生一起工作。他们使用Processing，arduino，Unity3D进行艺术创作，并且很少掌握技术知识。他们想使用我写的一些HTML5 / JavaScript。由于凉亭而采取的步骤
1. 从github下载回购的Zip（注意，在github上每个回购的右边。因为他们不知道git）
2. 下载并安装节点（因此我们可以运行npm来安装bower）
3. 安装git或msysgit（因为Bower需要它，并且它没有安装在许多学生的机器上）
4. 安装凉亭（npm install -g bower）
5. bower install （最终得到我们的依赖）
如果仅将文件检入github存储库中，则可以删除第2-5步。这些步骤对您我来说听起来超级容易。为了学生，他们非常困惑，他们想知道所有的步骤，其中，什么他们为这可能是很好的学习可能，但完全是垂直类的话题，所以可能很快被遗忘。
拉动时又增加了一步。

我执行过多次git pull origin master，然后测试我的代码，这需要花5到10分钟的时间来记住，我需要键入bower install 以获得最新的Dep信息。我敢肯定，可以通过一些拉脚本钩子轻松解决。
它使git分支更加困难

如果两个分支具有不同的部门，则您会感到困惑。我想你可以bower install每次都打字git checkout。速度非常重要。

至于您的正面看法，我认为每个例子都有反例

简化了分发和导入共享模块的过程，尤其是版本升级。

与什么？分发当然并不容易。拉回购而不是20个回购并非易事，而且更有可能失败。参见上面的＃1

从源代码管理中删除共享模块，加快并简化检出/检入（当您的应用程序具有20多个库时，这是一个实际因素）。

相反，这意味着您依赖他人进行修复。这意味着，如果您的部门是从第三方来的，并且您需要修复错误，则必须等待他们应用补丁。更糟糕的是，您可能无法仅获取所需的版本以及您的补丁，而必须获取最新的版本，而该版本可能与您的项目不向后兼容。

您可以通过分别克隆其存储库来解决该问题，然后将项目部门指向副本。然后，您将所有修复程序应用于副本。当然，如果您只是将源复制到您的仓库中，您也可以这样做

使您可以更好地控制或了解组织中使用了哪些第三方库。

这似乎是有争议的。只需要求开发人员将第3方库放在下方的自己的文件夹中<ProjectRoot>/3rdparty/<nameOfDep>。轻松查看使用了什么第三方库。

我并不是说没有积极的一面。我所在的最后一支球队拥有> 100个3rdparty部门。我只是指出，这不是所有的玫瑰。例如，我正在评估是否应该摆脱凉亭。

— man
source

哇，有很多否定票，没有一个正当理由。做得好！:(

— gman

我从未使用过凉亭，但是install每次结帐时的需求似乎都是设计缺陷。它在构建项目时应检查其配置：如果有更改，则应从头开始进行重建。另外，移动存储库与Maven无关，因为它从Maven存储库中提取工件，Maven存储库存储工件，而不是带有代码的实际存储库。如果您将其发布在Maven存储库中，则只能进行更改，artifactId并且只能groupId在其下一版本中进行。因此，您的第一点和第四点与Maven特别无关。＃3可以替换为mvn clean（有时）

— scriptin 2014年

确实，＃2并不是缺点-这是一个权衡。当然，您必须学习工具！例如，Git很难掌握，但是由于dem noobs的缘故，我不会放弃它。

— scriptin

看一看十二因子应用程序

特别要了解他们对依赖项的看法。您会注意到，良好的设计提供了一种用于定位依赖项的声明性机制，在Java中，这通常是通过Maven实现的。Ivy和NuGet可以很好地工作，但是Maven目前是该领域的领导者，而Ivy无疑是艰苦的工作。

如果您遵循Maven发行过程（在正式发行版发布之前就制作快照，切勿尝试覆盖以前的发行版，请使用Nexus或Artifactory等适当的存储库管理器），那么您应该拥有一个顺畅的构建过程。

一旦有了一个可靠的声明式构建过程，它便为其他良好实践打开了大门，例如与Jenkins进行持续集成，与Sonar进行持续代码分析，并且您会发现自己正在寻找使用git的更好的版本控制分支策略。

以上各项均基于Maven核心。如今，这几乎是明智的决定。

— 加里·罗
source

我看了《十二因子应用程序》，但它极富争议，只有一点点相关。同时推动Maven并不能帮助我解释为什么我们需要依赖注入。总的来说，这个答案并不能帮助我出售Dependency Injection，只是告诉我在构建过程中需要做的很多事情。

— C. Ross

依赖注入（设计模式）不是依赖管理（构建模式）。您已经涵盖了问题中所有最重要的方面。如果您的团队在听到这些意见后仍需要说服力，那么看看依赖管理将导致什么应该是最终的说服力。

— 加里·罗

在我们的前十名中排名第一的是...

（击鼓）

每个开发人员都使用完全相同的所有依赖项版本进行构建，因此您不必怀疑要在生产环境中部署什么。

— 罗斯·帕特森
source

与签入依赖项有什么不同？实际上，如果您不检查依赖项，则可能会冒一些第三方破坏发行版的风险。我已经不止一次发生这种情况，其中一些Bower Dep指向某人删除或重命名的回购。如果我只是将源复制到我们的仓库中，那么这个问题就解决了。

— gman 2014年