[播客]工件仓库和连续交付管道

版本控制是预测部署提前时间、部署频率和MTTR的最重要因素之一。为什么它对DevOps组织如此重要?

在去年9月的JavaOne期间，我参加了一个关于主题的在线小组构件库，作为持续讨论(#c9d9)的一部分，这是一系列关于敏捷、持续交付和DevOps的社区小组。持续讨论是Electric Cloud的社区倡议力量持续交付在SpaceX、思科、通用电气和E*TRADE等公司实现了构建、测试和部署流程的自动化。

请看这里的录音:

或者读读我对小组的一些见解:

工件存储库的好处

我对我们得到的答案很着迷，因为这正是我们从每个人那里听到的，我们试图成为用户反馈梦想公司，这与我们试图宣扬的完美一致。我所听到的是两件事,一是持续集成和部署的工具软件的管道穿过从开发人员到生产和自动化,Rest API,能够从任何方向连接,CI服务器从一边和另一边的部署工具,所有的合规和扫描和所有这些部分,这是一种纯粹的管,另一个是信息,我对工件的了解，关于工件的元数据，关于第三方工件的元数据，这又回到了什么是版本?一个版本就足够了吗?版本是否表达了工件的状态?当我查看工件时，我能知道它通过了哪个QA级别吗?它在我的连续交付管道的哪里?这些都是元数据。

我想说的是，工件存储库与将一些文件扔到某个地方并在那里获取文件之间的最大区别是两个方面。文件系统是愚蠢的，我们不太了解那里的文件文件系统对自动化不是很友好，当你有一个二进制工件存储库，它是一种文件系统存储，但有了这两层，你可以有关于工件的信息，你可以添加它，你可以查询它，你可以为你的部署工具自动化它，应该能够查询工件，给我所有来自最新构建的工件，但前提是它们通过了特定的质量关，并匹配目标平台，并且以自动的方式进行，这样我就不需要在我的交付过程中有任何人工干预。这两个与我想说的本质是一个好的工件存储库,它带来的不同的特点,例如它必须是通用的,因为它需要支持所有的在一个地方从自动化的角度来看也为信息的角度来看,因为您需要跟踪所有这些不同的部分从所有这些不同的技术到一条信息,你有一个Jar文件,当它穿过那些俄罗斯娃娃包内部的战争,包内Debian包，包内Docker镜像然后一部分Vagrant盒。当您拥有一个完整的Vagrant框时，您需要能够指出Java代码中哪行代码搞砸了所有事情。当你可以通过俄罗斯玩偶链获得元数据流时，你也可能需要一个工具，所以通用是一件大事，这是这两者的结果，自动化和信息。

企业回购的挑战:依赖管理和可追溯性

包管理是一个非常困难的领域，它看起来不是那样，感觉上也不是那样，从服务器获取几个文件并将它们放在文件系统的某个已知位置有多难，但几十年来人们都无法正确地做到这一点。我曾经说过，我称之为“依赖管理，欢迎来到地狱”，当我们把对它们的支持添加到我们的Artifactory和Bintray时，我们经历了我们在JFrog中学到的所有不同的打包类型，以及它们是如何糟糕，一些以相同的方式，其他以各种奇怪和不同的方式，但它们都很糟糕。

问题是这些问题会舔到用户，当门“npm取消发布”每个人都会遭受痛苦，这只是糟糕的设计NPM注册表但它影响每个人。嵌入到工件存储库中的依赖项管理旨在保护开发人员不受这些问题的影响。回到NPM门，一旦发生了NPM缓存所有用户都没有注意到，这对所有技术都是如此。当Maven Central现在作为NPM注册中心是一个完全混乱的时候，Artifactory开始作为这个盾牌，这是我们开始的，现在对我们来说绝对清楚的是，我们需要为我们所做的所有新技术继续这样做。

Docker hub每隔几天就会遭受巨大的缓慢，而且使用Artifactory的人甚至都不知道它。依赖管理是中央存储库的一部分，因为它是抽象的，并简化了用户的依赖管理，使他们实际上更有效率，对我来说这是最重要的部分。

昨天我做了一个关于Maven, Bazel和Gradle的比较。Bazel不支持传递依赖，而Gradle在早期也不支持。在maven中没有禁用它的简单方法，如果你有传递依赖和这类东西，你可以用maven Enforcer插件失败构建，但它是一种嵌入的，你没有禁用它的灵活性。我们与那些认为传递依赖是好事或坏事的观众进行了一次非常有趣的讨论。我认为这里的黄金路径是有传递依赖是一个非常严格的依赖管理，当你实际上可以确定版本而不需要处理依赖本身，如果你碰巧有这个包，确保它将是这个版本，但我实际上不关心你是否需要这个包，但如果你需要，使用它。

企业回购的挑战:分布式团队/应用/基础设施

局部性是很重要的，当我们讨论二进制时，我们讲过比特是如何容忍它的大小的，我们提到它是一个点。对于开发团队来说，将他们的工件存储库带到团队中是极其重要的，因为这是有延迟的，而且缓慢的工件存储库与其他任何存储库一样令人讨厌，您需要做一些需要花费很长时间来下载的事情，当然生产力也会下降。这是一种标准，在一个良好的高效工作环境中，附近有一个工件存储库，真正的问题是如何在所有这些工件之间进行同步，欧洲的团队在他们生产出工件后如何睡觉，美国的团队在开始工作后如何尽快得到这些工件。对于您的工件存储库来说，在本地安装非常重要，而且能够在任何可能的拓扑结构中同步，并通过所有的网络障碍(如防火墙)。

这是另一种我们可以谈论的局部性，我提到的局部性是对开发团队的局部性，但对你的CI管道的局部性是另一种。如果你的CI服务器在云中，那么在CI服务器所在的位置放置工件存储库是非常重要的，如果你使用Amazon，那么你需要在Amazon中放置工件存储库，如果你在谷歌cloud上放置工件存储库，那么你需要在谷歌cloud上放置工件存储库。这是一组完全不同的问题，我们通过在每个云和每个地区提供Artifactory作为服务成功解决了这些问题，所以如果你在这个地区没有你的CI服务器，我们将确保你的Artifactory服务器在那里。那是一个新的位置，它应该与我们之前说过的开发者位置同步。上面一层是管理所有这些东西,现在你需要有一个一致的配置在25服务器,10是一个大陆,在云中10在其他大陆,5,现在你添加一个新的码头工人生产库,你怎么能确保所有的配置都是相同的,和多长时间登录到他们实际上做的每一个变化。当您在世界各地推出工件存储库的企业设置时，您需要记住这一点。

好消息，最新版本的Artifactory可以清理未使用的层会自动使用，更重要的是使用基于存储的校验和，如果你有很多Docker图像依赖于相同的基图像，那么该基图像的所有公共层都将存储在新的层中。在我们编写的包管理中，有一些问题是我们无法解决的，这是依赖管理器的问题，不管他们搞砸了什么，我们都无法解决，但当涉及到存储和服务那些二进制文件时，我们会尽我们所能来改进。Docker是一个了不起的技术公司和杰出的技术人员的很好的例子，当涉及到所有这些Linux内核隔离进程和所有这些东西时，他们绝对是聪明和天才，但我们认为他们最强大的部分不是依赖管理和工件管理。

企业回购的挑战:安全性和治理

我们有两种安全顾虑，第一种是访问控制第二是内容控制。在访问控制中，我们需要从不同的角度来分离权限，首先它可以是真正的谁应该看到一些东西，但当我们谈论在室内环境时，这真的不是一个问题，因为通常人们被允许看到并使用来自不同存储库和不同组的包或工件。这种控制，我们使用它来确保任何需要的东西到达正确的地方，例如，我们不会在生产环境中以未测试的工件结束，不是因为我们是卑鄙的人，想要限制它使它成为“只需要的基础”，但仅仅因为当我们设置这些栅栏，当我们建造这些墙，我们可以保证任何需要从一个地方到另一个地方的东西不会混淆，并在其他地方找到它，当然，如果我们有公开的服务，那么对人的认证也是一个大问题。

另一方面是内容的信任，我们如何才能知道我们的包和工件中的内容实际上是安全的?我对此有复杂的感受，因为我知道有一些公司在开源是危险的威胁的基础上建立了自己的商业战略，在包装中有巨大的威胁，有时他们很幸运，他们会流血或其他什么，但通常我觉得这是一个威胁人们购买他们的产品的行业。另一方面，挖掘工件并找到其中的东西本身就是一个有趣的话题，不仅是为了安全，安全肯定是其中的一部分，如果我们能发现一个漏洞，那就好了，我不建议在此基础上制定策略，但能够做这种影响分析并了解这些东西，因为它很重要，它也有安全方面。

知道了在您的工件中发生的事情，不仅是为了安全性，也是为了许可证遵从性和性能，我想知道我的体系结构中是否有一些缓慢的组件，它是比知道我有一些漏洞更重要还是更重要?这可能也是一件大事。它主要是为了质量，而不是真正的安全，但它有助于构建两者。