管理软件项目的开源依赖关系是一种不辞辛苦的工作，每个人都认为这是理所当然的，直到他们被迫为自己做这件事。虽然大多数现代软件包管理器可以帮助使用单一语言的小型项目保持你的依赖关系，但随着复杂性的增加，软件包管理器的缺点变得更加明显。
例如，仅仅依靠软件包管理器来管理你的依赖关系会导致以下问题：
- 工具激增 --你的团队使用的操作系统和编程语言越多，你需要的工具就越多。这不仅意味着多个软件包管理器（每个操作系统和语言一个），而且还意味着多个编译器、打包器等，其结果是。
- 可用性 - 预置包并不总是适用于每个操作系统，在这种情况下，你必须自己构建它们。
- 版本锁定 --将依赖关系钉在特定的版本上是确保环境可重复性的最佳做法。但是糟糕的锁定做法会导致问题，当。
- 已知的漏洞得不到解决，因为升级到最新版本的软件包可能会破坏环境/应用程序。
- 只有顶层的依赖关系被钉住，允许暂时性的依赖关系随着时间的推移而转移，最终导致一个不可复制的环境。
- 消失的依赖关系 --不管你喜不喜欢，互联网上的东西都会改变。开放源码的依赖关系可能 被开发者删除 ，或者 被破坏，可能会破坏你的环境。
经历过上述一个或多个问题的组织通常愿意尝试不同的方法，比如实施一个工件库，为你的开发团队需要的所有开源依赖提供一个中央真理源。
这篇博文旨在帮助你了解在工件库中管理你的依赖关系的优点和缺点，以及如何以自动化、可扩展的方式进行管理。
依赖性管理的问题
没有哪个产品经理希望他们的开发团队花宝贵的时间来管理依赖关系。而很少有开发者愿意管理依赖关系而不是代码。因此，当涉及到软件开发时，依赖性管理就成了一个红头的继子。
不更新依赖关系的风险
当许多 报告 和 调查 反复确认这样一个事实时，这一点最为明显 ：一旦一个依赖性被添加到代码库中，尽管风险越来越大，从轻微到不负责任，它几乎从未被更新：
- 审核开源依赖关系变得越来越困难。
- 性能滞后，因为过时的版本错过了明显改善速度和/或功能的增强功能。
- 最终，有人被迫更新一个依赖关系，可能会破坏环境和/或构建。
- 你现在要用滚雪球式的更新来修复坏掉的东西，而这又会破坏其他的东西，以此类推，使问题变得更糟。
- 每个人的本地部署环境现在都是不同步的，造成了 "在我的机器上运行 "的错误和环境可重复性问题。
- 关键的漏洞没有得到修补，使组织暴露在网络攻击之下。
更新依赖关系的工作
但是，"如果它没有坏，就不要修复它 "的古老谚语仍然是更新依赖关系的强大阻力。嗯，还有所有涉及的工作，其中可能包括：
- 检查新版本的依赖关系的自述文件，以了解增加/改变的内容
- 在你的CVS系统中为修复创建一个分支
- 更新依赖关系
- 提交文件
- 解决不再与新依赖关系兼容的依赖关系集
- 重新构建/测试你的分支，以确保没有任何损坏
- 修复那些不可避免的故障
- 确保你的同事了解哪些地方改变了，为什么会改变
- 更新所有的环境，包括开发、测试、CI/CD、暂存等。
这种与管理依赖关系相关的风险和工作之间的鲜明区别是大多数组织最终造成大量自我伤害的地方。帮助平衡工作与风险的一种方法是使用工件库。
依赖性管理和工件库
工件库提供了一个集中的地方来存储已建工件，如开源依赖，并使它们对需要它们的系统和团队可用。但大多数企业也使用它们来：
- 为资产把关 - 大多数企业都有一个审批程序，在新的开放源码包可供使用之前必须通过。一个工件库可以帮助充当一个闸门机制，使新的开放源码包只有在被批准后才能被组织使用。
- 管理漏洞 - 许多工件库还包括识别和通知用户开源依赖性漏洞的能力。
- 确保兼容性 - 通过资源库提供的所有开源依赖可以预先确定在一起工作，解除了开发人员独立解决依赖冲突的需要。
- 确保安全 - 具有安全意识的企业通常从源代码中构建所有的开源依赖，并手动将其填充到工件库中。这就避免了从没有提供安全保证的公共资源库中摄取预构建的组件所带来的风险。
在这些方面，工件库可以成为集中管理所有开发团队所需的一套标准开源依赖关系的绝佳方式。然而，虽然工件库为管理依赖关系提供了一个重点，但它们并没有将这些任务自动化，这可能需要大量时间和精力。
依赖性管理自动化
通过将工件库与ActiveState平台相结合，企业可以将许多耗时的手动依赖性管理任务自动化，包括从源代码构建依赖性，寻找和修复漏洞，并确保安全。
