用例——Artifactory作为持续交付工具链的骨干

讨论转录:

谢谢大家今天下午来参加我的节目。我叫克雷格·沃斯伯格。我在CA科技公司工作。我在首席技术官的办公室工作，我已经在这家公司工作七年了。通过收购，你会发现我们很多公司都是这样进入加州的。我的个人背景是，我从事软件开发已经超过25年了。我在管理方面和个人贡献技术方面各占一半。我现在以个人贡献者的身份回来为CTO工作，做一些我今天要讲的事情。关于工具转换和公司内部的东西。在此之前，我在我们的一个业务部门用一种特定的产品扭转了局面，在我们讲这个的时候我会把它作为一个例子。

所以我想我应该先开个口，做个铺垫。因为我们可能和其他一些人不太一样，我们不是，你知道，我们是中型到大型的-哎呀。我把东西扔上来了。所以我想为我们设定一个环境是什么样的，诸如此类的东西。

所以。首先:谁是CA技术公司，我们在哪里?我们公司有大约11000名员工。就像这样。从发展的角度来看，我们有大约3500人。我们分布在大约20个地点，就是你在地图上看到的那些。这些都是大的。实际上我们还有很多。我们倾向于通过收购实现增长。所以当我们把公司拉进来时，我们最终会有一堆小网站，诸如此类。 We don’t have a model of strictly trying to pull people in, you know, like the old Microsoft model used to be where everybody, when they got acquired, got moved up to Redmond or something like that. We don’t have that kind of model, so from a development standpoint, we need something that works in a very distributed, geographic environment.

从收入的角度来看，我们所做的事情还远远不够。所以，你知道，我们是一个相当大的公司，就我们的工作而言。多种产品，多种不同hth华体会最新官方网站的总线。我们在安全领域工作，在基础设施管理领域工作，在应用程序性能管理领域工作。在过去的几年里，我们在敏捷和开发运维方面做了很多事情，并开始转向能够做这类领域所需的大量协作方面的工作。

继续，我们看待敏捷的方式。正确的。在这张幻灯片的底部，我们会讲到这里。幻灯片底部基本上是标准的敏捷。安全的东西如果你能看到的话，对你来说可能有点小。你知道，产品负责人，scrum管理员，诸如此类的人都在最下面。如果你是一家中小型公司，你在一个地方运营，你没有多种产品，这类的东西，答案是，这可能是你必须达到的最高水平。hth华体会最新官方网站正确的。

对我们来说，我们在那里花了很多时间，因为我们有多个不同的业务部门，我们把它们分布在世界各地。所以，你知道，我们有一个单一的产品线，比如安全，将有十几种不同的产品分布在世界各地。hth华体会最新官方网站我们的产品组合中有十几种不同的产品。hth华体会最新官方网站这些产品通常hth华体会最新官方网站不在同一站点，所以我们为任何给定的产品分散在不同的地理位置。这就增加了一些额外的挑战。

很多人看到这张幻灯片就会说，天啊，这过程可真够复杂的。所以我想说的是我们把它当做背景。所以这不是为了过程而过程。我们基本上是从这些材料中挑选出解决问题的部分。对于我们的一些较小的BUs，当你进入投资组合管理和类似的东西时，他们没有这些上层的东西。但是一些大的公共汽车公司，他们在上面花了很多时间试图弄清楚他们要如何把钱投资到馅饼上。这只是一个背景。这就是我们如何看待敏捷和扩展敏捷之类的东西。我们沿着这条路走下去，一开始，我们试图自己构建这个过程。在几年的时间里，我们发现，哇，这是很多工作。 It’s a lot of training materials, it’s a lot of getting out in front of people, and we got plugged into the safe stuff about the two-oh point and did the wow that’s actually pretty close to the stuff that we’re thinking about wanting to do. And so we jumped over onto their bandwagon at the beginning of the three-oh stuff and they’re now up to four-oh. So again, just as a bit of a backdrop for kind of the way we think of the problem as we go through it.

几乎所有做过收购并且拥有庞大产品组合的人都有这样一幅画面:你发现自己坐在这个董事会前面说，哦，天哪，对。我们到底是怎么看待这件事的?我们如何把这些东西整合在一起，我们如何建造这些东西?我们有一些新产品。hth华体会最新官方网站我想说的是我们去年收购的拉力产品。这是一种开发运营模式，他们每天都发布产品。我们还有其他20年前的产品。hth华体会最新官方网站我们有些产品已经有50年历hth华体会最新官方网站史了。我们有一大块主机业务。所以在过去，我们没有任何这些开发运维工具，所以答案是我们有一些看起来像这样的图片，我们必须弄清楚如何让它看起来更敏捷。 How do we actually get to a common tool chain that can actually have leverage across the organization as we go forward.

那么在这些图片的背景下我们被要求的是什么呢?所以我们在地理上是分散的，我们正在扩大规模，我们有很多不同的组织必须在地理上扩大规模。在某些情况下，我们有一个巨大的意大利面条代码库，因为产品已经存在了很长时间，但是，对，我们被要求从每月到每年交付这些东西，降到hth华体会最新官方网站小时，周，你知道，一个月之类的边界。所以我们要弄清楚，如何对这个问题进行换皮。正确的。

对我们来说，一切都始于。哦,抱歉。在我讲这个之前，让我们先看一个例子然后再讲我们是怎么做的。

这是我们的一个例子。我去掉名字是为了保护无辜的人。这张幻灯片是关于2014年的，在他们开始搬迁之前的几年。所以，你知道，他们是这样的。正确的。他们使用的工具前后矛盾且过时。我会说他们的工具在90年代末，21世纪初，就他们所做的和如何做的而言，有点停滞不前。

他们的构建工件都存储在SCM(源代码控制管理工具)中，而不是放在Artifactory之类的东西中。这实际上是我们的第一步。

从构建的角度来看，它们是一体的，所以所有东西都打包到一个构建中，这个构建花了很长时间才能完成。发布周期:18-24个月。这就是它的由来。当然，这是On Prem的产品。所以他们所处的环境是他们在很长一段时间内大量生产，这是一个瀑布式的过程。

有限的自动化，对。所以我们用了2300天的手工测试来测试这个产品。正确的。这意味着如果我有100个人在做，我基本上可以在一个月内完成。你不能让100个人来做测试所以它就变成了长杆。当我们在研究这个东西的时候试图减少这个的后端。

我们没有“完成”的定义。所以当你开始转向敏捷时，你开始被国防部占用，诸如此类的事情。这些人在拍摄这张照片的时候已经采用了敏捷，但是他们做了什么，他们读了这本书，然后好吧，我们只是把它扔掉，把它放在一起之类的东西。他们没有做很多事情，实际上使敏捷在模型中取得成功。“完成”的定义是他们还没有完成的事情之一。所以他们基本上是在sprint中工作，但他们基本上只是在准备好了的时候投入代码之类的东西。他们没有任何正式的晋升程序。

没有代码覆盖，对。我非常相信某种程度上的制衡，对吧，并建立了“完成”的定义，即我希望团队能够执行的内容。然后我想要工具链中的一些东西，实际上可以给我一个完整的检查，就代码质量而言，以及东西是否被遵循。

很多技术债务，你会看到我们添加了一个工具来帮助跟踪其中一些事情。我们在那个特定的代码库中有很多死代码，几年前人们做了一些糟糕的事情，他们没有使用源代码控制管理工具来实现它的设计目的，并实际修改东西，他们实际上复制了源代码库的大块，对吧，当他们在做一些事情时，把它放在一边，因为他们当时没有任何功能分支或类似的概念。然后优先级出现了，永远不会被清理，所以有很多额外的代码隐藏在代码库中。我们花了很长时间才找到这些东西并将其根除，所以我们想要确保有一个工具能够做到这一点。

我们有一个单独的维持模式，这是我不喜欢的。我不喜欢由一个独立的团队来维护我的代码，而不是由一个实际从事开发工作的团队来维护。我想让它回到主线，否则你就会陷入分支问题，你就会陷入一大堆所有权问题，诸如此类的问题。

正如我已经提到的那样，没有功能隔离。我们的技能不匹配。我在这里讲这个，这就是全部，当我们进一步深入到这里的演示时。所有这些更多的是关于工具和过程，以及我们如何使用Artifactory和一堆其他工具来实现东西。但我只是想确保人们明白，你知道，工具只能让事情在自动化和诸如此类的东西方面变得更好，对吧。他们不能解决一些组织问题。因此，在技能不匹配和敏捷采用不佳的情况下，这个被称为黄金时间的东西，是我实际上不得不回去与业务部门的实际所有者一起工作的事情，这样我们就可以真正地重组他们做事的方式。在这个特定产品的案例中，他们实际上，一开始，在大约23个不同的网站上，直到只有几个人的网站。我们最终把它们缩减到大约五个地点。当一切都说了，做了，必须重新平衡技能。 So I just wanted to throw that out there as, you know, you’re going to see a bunch of stuff around tools and it all looks great but the answer was a bunch of the stuff that happened in here was predicated on having to make a bunch of these organizational changes.

这就是CA的一个例子的背景，对吧，一个我们拥有的更古老的产品之一的例子，我们必须修复它。hth华体会最新官方网站那么，我们需要做什么呢?我们要做的第一件事就是得到一些替换的CI/CD工具链，这样我们就可以让这个东西以更相关的方式工作。我们的第一步是，基本上，你在这里看到的，作为一个集中的解决方案。我来看看上面的不同组成部分。

顶端是Artifactory。对于我们来说，最初我们使用Artifactory只是为我们所有的构建做工件管理。所以我们把这些东西从源代码控制中拉出来，这样它就不会被修订，基本上是用来在后期构建中放置工件的。所以我们有一个地方可以去获取他们，可以给他们版本，可以把他们带回来。我们以后再谈。随着我们的发展，我们使用Artifactory做了更多的事情，但那是我们最初的东西。

GitHub。企业。具体来说。在我们的案例中，我们有一个大的讨论-我们是一个相当古板的公司，当涉及到IP和类似的东西。所以有很多讨论，你知道，我们能不能去外面的GitHub做私人回购，经过一系列的对话，答案是不，我们不能。正确的。你知道，这是一个价值40亿美元的业务，我们对这些东西负有受托责任，所以我们做了下一件大事，对我们来说，那就是吸引GitHub企业。特别是在GitHub Enterprise之后，而不是其他各种各样的工具，因为我们想要的，一个:整个社会编码的概念。正确的。我们想要弄清楚，我们是如何开始在公司内部把这一点融入我们的DNA的。 And so we’ve gotten — GitHub’s been up and running for about 18 months I think at this point. We’re just starting what is a inner source program. We’re sort of riding on PayPal’s coat tails on some of that. And the selection of going with GitHub has actually worked out really well for us because it’s got a bunch of those things that are already in there. We’re also getting a fair amount of lift off of — we’ve got a bunch of kids coming out of school, and what do they have experience with, they got experience with a whole bunch of GitHub and that kind of stuff. So it transitions easily from a skill set standpoint.

TeamCity和Jenkins。这是我们的两个主要CI环境。TeamCity算是首创，Jenkins是草根类的。我对ci采取的方法是，当涉及到编辑时，就像宗教一样。正确的。你有一些讨论，Vi更好，Emacs更好，Eclipse更好，答案是，我不想争论这个，对吧。我想-你从CI的角度找出什么对你是最好的答案是我们想让你在环境中发挥作用。所以我们采取了一种非常开放的方式。我们开始看到更多的Travis和类似的东西。但是，你知道，两个主要的，我可能会说，你知道，60% - 70%的人现在在TeamCity上，然后剩下的，你知道，在Jenkins上，还有一小部分人在其他工具上。

到目前为止，上面的所有东西，都用绿色标记，基本上，它们都是on Prem，我们自己运行这些东西，我们自己托管这些东西。

接下来的两个，CA敏捷中心和Flowdock。敏捷中心是我们为Rally重新命名的名字，所以这是我们做计划和缺陷跟踪之类事情的地方。它是一个基于SaaS的解决方案，所以我们使用它就像我们的客户使用基于SaaS的产品一样。Flowdock，如果你不知道那是什么，如果你熟悉HipChat或Slack，对，它是一个ChatOps工具。Flowdock的名气来自于几件作品。第一，与敏捷中心产品更紧密的集成，这样您就可以在开发人员工作的地方与开发人员见面。因此，开发人员不必从他们的浏览器，不好意思，不管是他们的ID环境，还是他们的聊天环境中，能够对某个任务或缺陷进行更新，或者其他什么，我们试图满足他们的需求。我们正在把这个功能放到Flowdocks中，这样他们就可以进行更新，从而进入Rally产品或CA敏捷中心产品。这样开发者就不用退出了。你还可以从另一个方向得到所有的集成，所以所有这些工具，对吧，在构建方面，在促销方面，任何类似的东西，所有这些东西都回流到[…]回到它里面。 So it allows our developers to sort of have one stop shopping to be able to figure out what’s going for the different products that we have.

接下来我们添加了SonarQube。这是专门用来解决代码质量问题的。能够看到它们，而不必派人去寻找它们。目前在内部托管。对我们来说，这是一个很好的工具。为我们做了两件主要的事情。第一个是关于-它有技术债务的概念，它-它-计算。不要计算，因为它实际上在理想的日子里完成了。不要把这当做福音。正确的。 It’s, you know, again opinion in terms of how the calculation works. It’s more a trend. I use it more like a barometer. Right. So you get a baseline for the environment and if you get somebody who’s cut, copying, and pasting a bunch of code in, the answer is you’ll see it happening in the environment. Right. You can see it actually start to creep up and see where you’re picking up the extra debt.

SonarQube的另一个功能是扫描代码覆盖。代码覆盖的多语言支持。这给了我们一种制衡。我之前提到的一种产品，你知道，它的含铅量要么是零，要么是10%这取决于它是拼图的哪一块。您知道，通常对于一个健康的项目，我希望代码覆盖率在65%到85%之间。这是我的经验法则，我们倾向于用它来处理这些事情。

最后一个我们要讲的是黑鸭。这是我们在第三方扫描时使用的。我们有一个，实际上仍然在使用，内部构建的解决方案来做这些事情。但有一件事它不能像黑鸭那样做，这是非常巧妙的，那就是能够找到头文件没有出现的第三方属性代码。所以你有一个开发人员，找到了一段代码，然后说，哦，我喜欢，剪切，复制，粘贴，然后把它放到我的源代码库中。如果它来自某个GPLed，那么答案就是你已经拖累了你的代码。正确的。这些都很难找到。正确的。很容易找到有版权标题之类的东西。 Black Duck has the ability to go do those kinds of things, right. And so that’s another one we added into the bag of tricks that we have. What I would say in terms of Black Duck is it can take a fair amount to do the initial remediation against a older code base, right. So it will go through and find lots of stuff and you have to then go sort through it, and tune it, and that kind of stuff. The good part is once you get all of that stuff out the way, get the debt out of the way, then the answer is much like SonarQube, it gives you a nice baseline. You can see how your code is working, basically day to day as the stuff’s getting built through the environment.

这就是我们在18个月前推出的核心解决方案的一部分。在一个中心环境中推出，然后让人们开始使用这个产品。

我们再举一个例子。这是我们的一个业务部门。因此，在我们拥有的20多个地点中，它们归结起来大约有9个。正确的。所以他们把他们的代码转移到GitHub环境中，他们把自己设置到工具链中，他们让他们的构建工作，所有的事情。在性能和诸如此类的东西方面看到了一些非常好的改进-在构建时间方面。但他们仍然有问题，实际上，你知道，一大堆辐条都回到一个中心，在某些情况下，相对较高的延迟和低带宽链路。所以如果你不得不移动文物之类的东西，答案是很痛苦的。

所以，这已经基本被发现了。我们做出这一举动后遇到的两个主要问题。第一个是关于构建工件的。对于我们的一些On Prem产品来说，有几个gb的空间是很常见的，比如从构hth华体会最新官方网站建中生成的20 gb的安装材料。如果你必须把它拉回你的本地网站，答案是，它真的是被禁止的。所以人们做的第一件事是，哦，我们可以自己解决这个问题，我们会做一个小小的影子IT，我们会把一个小小的开发人员栏插入到一个小小的服务器框中，在某人的开发人员桌面下面，我们会继续在本地进行构建。

这就引出了第二个问题。正确的。现在你所拥有的是一群人都在通过网络进行源的拉取。这就有问题了，因为当你开始有越来越多的人以一种自动的方式进入资源基础时，你实际上开始影响那些试图完成日常工作的人。他们试着做拉请求，把东西整合回来。我们在运行的过程中给系统施加了很大的负荷。所以我们后退了一步，花了一点时间研究，嗯，我们能做些什么来解决这个问题，考虑到我们有这么多技巧，我们有这么多工具，诸如此类的东西。我们最终采用的方法是，我们需要在我们的中心上放一些辐条。我得找个能让我骑着的轮子。

这里的一般概念有点像CDN，对吧。所以我们希望能够在边缘提供一些构建功能。所以我们希望能够让在柯林斯堡的人，或者在布拉格的人能够让他们的构建是本地的，但我们也希望能够实际地将代码发送到他们所在的地方。所以他们是在10g的网络上进行拉取，而不是在广域网上。我们希望能够获得工件管理到边缘，这样我们就可以实际检查正在构建的工件，这样如果其他人是那里的开发人员，想要构建项目，他们也可以在10gig网络上做那些事情。所以我们就有了这个想法我们要给自己造一个可以展开的辐条。所以我们花了一些时间讨论，我们想要的目标是什么，你知道，一种辐条式的环境。

我们确实想要一些可以根据需要复制工件的东西。让它变得简单。这绝对是Artifactory的最佳位置，这也是我们一直在使用它的原因之一，我们只是继续在产品中添加新功能或启用新功能。

我们希望能够在几分钟内创建新的边缘环境，而不是几个小时，几天，几周，有时几个月。能够把东西支撑起来，因为，你知道，这可能是我们的IT部门试图在布拉格或柯林斯堡做事情，在那里他们不一定拥有在其他环境中拥有的所有相同的资源。2022世界杯阿根廷预选赛赛程所以我们想要一些相对来说包装良好的东西。我们想要最小化边缘处的构型。正确的。所以我们想要一些东西，理想情况下，答案是一个团队过来说，我需要一个新产品的环境。答案是，你知道，在几分钟到一个小时内，对，答案是，你有了你可以工作的环境。

我们想要一个能够自动更新的解决方案。所以我们需要一些我们不希望IT人员接触到的东西。正确的。这对他们来说很麻烦，如果他们要不断接触和升级所有这些盒子，并能够保持他们的补丁版本和其他一切。所以我们需要一种推动模式。我们实际上开始处理我们自己的基础设施，看起来更像是基于SaaS的模型，而不是典型的On Prem部署，你知道，把它插入Puppet或Chef或类似的东西，然后以这种方式推出，你试图进化环境。

我们想要一些会在我们内部IT基础设施上运行的东西。我们曾经做过很多我们称之为影子IT的事情。正确的。这就产生了问题。因为它是一堆没有被管理的盒子，没有在补丁修订中被保持，没有固定的断点，所以你最终会，你知道，一些东西在最终构建完成之前的一个周末就死了，答案是:抱歉，它实际上没有被任何人管理这是你的问题，你是构建它的人。所以我们最终陷入了相互指责。所以我们想要的部分解决方案是——我们想要明确的角色和责任，在这种环境下谁要做什么。

然后我们想要动态缩放的能力。就在那儿。我刚才漏掉了重点。想要动态缩放环境的能力。所以我们往往会发现人们一开始会把它设置好，他们会觉得这很酷，现在我想在上面放更多的东西。我希望有更多的项目与之对抗。这意味着我们需要额外的构建器能力，无论是Jenkins构建器还是TeamCity构建器。所以我们希望这个机制能够在我们工作的过程中自动按需扩展这些东西。

我们也有一些边界条件。就我们想要确保的一些技术而言，我们被卷入了这个问题。从右边开始，到左边。Nutanix。如果你和我们内部的IT团队谈过，Nutanix盒子有点像盒子里的云。正确的。它有计算，有网络，有存储。这对他们来说很容易管理。他们可以对其进行配置，并将其部署到边缘。所以我们希望它是Nutanix，因为我们希望它能与我们内部的it团队很好地合作。

它将在此基础上加入VMware。我们马上就会讨论这个问题。但这是VMware，因为这是他们管理基础设施的方式。所以这是一个相当大的物理容量，但是他们把VMware放在上面，并能够使用它来运行一堆不同的虚拟机。

事实证明我们的解决方案不需要任何特别的东西，但再次，回到试图得到一些容易被润滑的东西。从开发的角度来看，我们所有的工作都是在CentOS上完成的，这是因为我们主要是红帽公司。所以它是二进制兼容的。但是不需要为那些已经存在的项目做许可这是CentOS的一个原因。

我们想要使用Docker，这就是它与VMware对话的地方。Docker，因为它解决了我所说的一些问题。所以把一些东西打包部署，当它在现场时能够升级，能够动态扩展，对吧。这些都是Docker为我们做得很好的事情。所以我们想把Docker加入其中，但是，你知道，人们会问这样的问题，为什么你把Docker放在VMware之上。这似乎效率不高。答案是，是的，有一点，但对于我们现在要做的已经足够了。随着时间的推移，我们的计划是，至少在边缘节点上，将VMware组件移除，因为我们将在这一层的许可成本方面获得相当多的回报。但我们不想从那里开始，因为我们正试图与现有的IT基础设施很好地合作。

然后Artifactory将成为，我们正在做的事情的骨干。我们要把一大堆辐条从轮毂上推出来。我们现在需要一种机制，能够复制在不同地点产生的不同组件，以供其他需要使用它的人使用。这就是我们把五大技术混合在一起的时候我们开始尝试找出解决方案的样子。

回到过去，但我们不会成功，除非我们通过一些改变来经营。正确的。因为我可以把最好的工具放在那里，但如果它仍然是一个巨大的整体，每个人都必须一直接触所有东西，这是行不通的。因此，与架构团队一起工作，基本上开始解决这些困难的问题。正确的。如果你有一张像这样的图，对，答案是你必须做一些艰难的提升才能真正解决这个问题并把它分解成一堆分量。如果你有这样的东西，而且只在一个地方，你可能不需要太担心，对吧，因为答案是每个人都在一个地方工作，但一旦你把它分散到很多地理位置，答案是你需要特许。你需要站点拥有环境的组件，这样他们就可以隐藏在API后面，他们会为他们正在做的事情做一大堆修改，但是他们会保持外部API的一致性。

它允许那些依赖于他们的人使用Artifactory作为复制机制。你有一个小组在迪顿公园他们在研究代理树。他们会让他们的东西开始工作，他们会让它合格，测试它，其他的一切，并把它作为一个工件作为最终的二进制文件，其他人只是简单地把那个二进制文件拉进来。这个二进制值可能只会根据他们所做的工作每月变化一次。这意味着我们不会有太多的网络流量，这是一个非常有效的方法来完成事情。但如果你没有解决这个问题，它就不会起作用。对我们来说，在并行的情况下，我们开始用不同的产品团队来解决这个问题。

所以现在我们回到了同样的画面我们仍然有9个地点但不同的是，不是有一个巨大的单一的东西在所有的地点都是花生酱每个人都在做每一件事我们实际上开始有这些不同地点的特许。他们在解开谜团。正确的。所以他们的组件可以被检入，然后能够被环境中的其他人使用。

然后我们来看看它的实际样子。这就是我们现在的辐条的样子。然后我就会把上面的组件都讲一遍。最下面的Nutanix，我们已经讲过了。这基本上就是我们将部署出去的盒装云基础设施。VMware在上面运行。现在，VMware可以运行多种不同的东西，但它只运行Docker环境，因为这就是我们在解决方案中使用它的方式。我们在用道克和CentOS。我们使用Docker来添加Kubernetes之类的东西，或者使用OpenShift，或者添加Mesos或任何这些层，因为我们在寻找简单。而且，你知道，我们并没有很大的需求来扩展这个方面，除了找到建造者，结果我们解决这个问题的方法有点不同。 So a Docker solution using, you know, if we need to get into some of the automatic scaling using the swarm functionality but allowing us to just use compose, as our mechanism to prop these things up, was sufficient and sort of kept the problem reasonable in terms of complexity.

再往上走，右边的三个方框，詹金斯就是标准的詹金斯。其实我们用的是现成的詹金斯。今天早上的那位先生谈到了一些最佳实践，我发现自己在经历战争的过程中对我们的战争创伤和教训点头。对我们来说，我们基本上拉出了基本的Jenkins图像，我们只添加了一点额外的插件，我们特别想在每个网站上都有，然后我们基本上签入了。

我们在Artifactory查过了。我们确实遇到了一个先有鸡还是先有蛋的问题，在你试图设置这个东西的时候，Artifactory没有运行，所以我们要做的是，我们回到枢纽，使用枢纽的Artifactory来维护所有这些图像，能够把它们拉下来。但除此之外，詹金斯基本上就是标准的詹金斯。从构建器的角度来看，我们有几个基本图像。同样的事情，我们试图建立一个每个人都可以使用的图像，这样你就不会从这些图像中得到巨大的延伸。所以，你知道，在我们目前的一些产品的技巧包中，我们有一个Ubuntu映像，我们有一个CentOS映像来进行我们的构建。hth华体会最新官方网站我们加入的是，你知道，一些仪器来做一些事情。我们添加了特定的库，我们需要能够插入到我们的环境中，好的部分是其他人可以选择它，对吧。他们基本上只是做了一个，从那一个开始，添加到他们的构建环境所需的其他部分，他们就能够做事情了。

这些都是很通用的，和你通常看到的一样的标准功能。

看下一个，这里有个东西叫Git缓存。所以我们发现我们需要一个Git的CDN。但是Git没有这样的东西。正确的。因此，我们需要一种机制，能够将源代码复制到边缘，并保持其为只读缓存的最新状态，这样我们就可以允许人们进行克隆。大多数情况下，开发人员会频繁地进行这些克隆，但如果开发人员需要一个大的工作空间，他们也可以利用同样的东西。我们在这里建立的centos7image是它的基础，你基本上把标准Git放在上面这样我们就有了一个能够管理环境的机制。

你进入到中间的部分，叫做RepoSync这是我们写的一个小NodeJS应用程序。我们的计划是开源。正确的。这样其他人就可以利用它。我碰巧是GitHub的客户顾问委员会成员，所以我们正在努力吸引其他对这个功能感兴趣的人。所以我们要把它放到外面。

这个东西所做的基本上就是监听网络钩子，然后它做一些神奇的事情。所以我们试着回到那个前提，试着在我们放入的边缘节点上没有配置-这个东西的所有配置实际上都发生在GitHub中。所以你进入GitHub，你说，我想复制一个给定的工作空间，通过放入一个网络钩子，并将它指向这个中心的地址或这个辐条的地址。一旦你把它放进去，点击保存，它就会发出一个ping。这个ping请求被这个消耗掉，然后它返回，告诉我所有关于那个回购的信息。

它做的第一件事是克隆回购并将其拉下来并将其放到本地机器上。然后它转过来，找出谁是所有有权访问这个回购的用户，他们的隐私是什么。然后它会计算出这些用户拥有的SSH密钥并将所有这些东西复制下来并放到本地机器上。然后，网络钩子使它保持最新。正确的。如果有人进来，改变了一个SSH密钥或者有人进来，改变了一段代码或者拉出一个请求之类的，网络钩子就会触发，这个东西会自动把信息拉回来。它能在几秒钟内保持同步。正确的。这不是双面提交，不是你把它放到主存储库中，它就立刻被删除了，即使是在慢速链接中，你知道，通常它的秒数是你得到的，就传播改变所花费的时间而言，一旦你得到了初始的克隆。

从技术角度来看，这只是一个正在运行的小NodeJS应用程序。我们使用Node是因为它是多线程的，并且能够在其中设置restful接口来消费东西是很简单的。当它使用Apache和GitoLite时。

Apache使用了Git中的一个原型。就是能够跨HTTPS做一个克隆。这就是Apache的作用RepoSync将数据拉到存储库中进行存储然后有效地提供两种方式。通过Apache路径提供它让人们能够通过该机制进行克隆或者，更典型的是，在我们的环境中，它通过GitoLite提供它以便能够对这些环境进行SSH访问。

GitoLite是一个现成的产品，它是开源的。它所做的是根据你拥有的一组SSH密钥来管理所有的访问权限。这意味着所有的魔法能够确保适当的特权被保留下来，所有这些都被委派到GitoLite，因为它为我们处理这些。

所以，你知道，经过几周的工作，我们最终得到了一个有效的缓存，它是只读的，它在边缘运行，允许我们的人能够让我们的构建者能够直接从10g的网络上的本地文件中取出东西。你可以想象这在性能上有很大的不同。就他们的构建时间和诸如此类的东西而言。我们马上会讲到一些数字。

我想这就差不多了，我们继续。

我们来谈谈Artifactory，因为它仍然是基于Artifactory的。我们开始使用越来越多的功能。所以我们有了这个中心和辐条的架构，我们现在把一个大的、单片的代码块分解成各种各样的repo。我们现在有不同的网站，他们拥有自己的拼图，他们以任何他们需要的频率转动它，对吧。每天都在不断地进行构建，但如果他们想发布一个新版本，每天获得一次资格认证，那就太好了。如果他们想每周做一次，那很好。如果是一个月一次，也可以。正确的。我们的想法并不是试图对每个人都施加强制要求，而是如何工作，而是提供一套接口，让我们能够相互隔离。这就是Artifactory为我们提供粘合剂的地方。

所以每个人都签入一个本地Artifactory实例，然后他们的依赖关系基本上被映射到其他需要的实例。我们可以设置缓存，我们可以设置自动推送，当环境中的东西更新时。它成为了Docker图像的一站式购物场所。所以，嘿，我提到了办公室里的人，你知道，似乎每次我发现自己在说，天哪，我希望，你知道，我有一个废话，在某种回购或能力或类似的东西方面，我去戳一下Artifactory内部，看，它已经有了。正确的。

我们在NodeJS功能方面做得不多。正确的。NodeJS需要NPM的Bower。进去一看，果然有。正确的。你知道，我们是一个CentOS环境，所以我们的存储库是基于YUM的。所有这些东西，如果你从外部网络获取它们，你会减慢所有的构建时间，对吧。现在我们把它放在Artifactory里面，这样它就为我们缓存了所有这些东西。今天早上关于Docker设置回购的最佳实践的评论是，你有一个开发环境和一个prod，所以你在两个独立的回购之间促进。和我们的模型一样。 The image we’re actually running for Artifactory is Artifactory’s image. Right. I love it. Right. I don’t have to worry about, you know, building it, maintaining it, all these kinds of things. All the patches come down for me, right. All I have to worry about is basically externalizing the storage and backing it up on this node. And we can then take the updates that come down from Artifactory, much like the same model that we have going on with the GitHub Enterprise functionality. Although in that case, it’s a VM that we use.

这里要提到的另一件事是Bintray。这对我们来说是新的。我们只是在把它发布出去的过程中。作为一家公司，我们开始将我们的应用程序打包到Docker容器中，以便于尝试和购买类型部署。正确的。所以，为了能够推出一些东西，让客户很容易地下载它，支持它，让它运行。通常，我们的许多On Prem产品都有很多旋钮可以转动hth华体会最新官方网站。正确的。我可以在这样的操作系统中使用这样的数据库和这样的网络服务器。正确的。 And so it makes for a fair amount of complexity for the installation. The cool part with the Docker stuff is we can basically fix all of those variables on the edge for a try and buy kind of environment. Right. If you just want to take it out for a spin, you’re just looking to see where the functionalities like, then the answer is that we can fix all those dependencies and basically provide you with an environment.

那么问题来了，我们如何为客户提供这些服务?正确的。我们可以把这些放到，开源或开放的环境中进行下载，但对我们来说，我们想要一些东西与我们的内部系统捆绑在一起，能够确保这个人真的是客户，能够访问它，如果他们要具体地查看取决于他们正在查看的组件-他们正在查看的产品。所以Bintray就是我们做这个的机制。这是另一种能力，我们知道，我们只是在利用它。所以对我们来说，Artifactory已经成为主干，基本上，我们用它来管理我们所建立的分布式环境。到目前为止，我们对所提供的功能非常满意。

所以。我们这里的变化所带来的影响。所以我将在这里介绍一些目标。所以已经开始看到价值了，不是所有的东西都推出来了。正确的。这一堆东西，枢纽里的所有东西，都很好。所有的东西都摆出来了。你会看到辐条里的一些东西，这些东西现在正在展开。但我们已经开始看到它的价值，尽管现在还没有完全实现。

那些有复选框的东西，都在工作。你们在那里看到的这对夫妇，你知道，正在进行的工作，其中一个是关于自动进化的能力。还没讲到那个呢。我们认为我们知道如何做到这一点，因为我们选择了Docker作为我们的技术支撑。因为我们建立了Artifactory作为我们的repo因为我们有一个测试这些东西的机制。我们相信这对我们来说将是一件相对直接的事情。为了能够设置一个cron作业，对吧，它会输出并且能够定期比较与图像相关的哈希值如果哈希值发生了变化那么答案就是我们会通过一个反弹，把它带回来。那将会在任何正确的时间发生，你知道，通常是在半夜发生对于我们碰巧运行的给定地理位置。

所以我们认为我们知道如何扫描它，它还没有被列在列表的顶端，因为我们到目前为止只把它推广到几个不同的领域。另一个是动态缩放的能力。现在我们用的是更传统的模型。你基本上是在那种环境下支持建造者来提供产能。工作得很好，但它没有给我们我们想要的东西，也就是动态缩放的能力。

我们研究了几种不同的方法来审视这个问题，我们要解决的一个，看起来，基本上是按需建造者。正确的。你去找Jenkins Jenkins会说，我要去TeamCity上安排一些事情或者我要去安排一些事情。答案是我们要及时地支撑起建造者，让它能够完成它的工作。一旦构建完成，我们就把它拆了。所以它给了我们一个非常动态的环境来管理东西。这是我们研究过的问题之一，我们研究过蜂群机制，Kubernetes机制，有很多不同的方法来解决这个问题。我们认为这将是最适合我们公司特定需求的一种。这些即将到来。

给出一些数据，这对我们有什么帮助。正确的。所以我说的最初的产品是遗产，对，它真的很大，分布在很多网站上，诸如此类的东西。所以最初的建造时间大约是16个小时。正确的。才能让构建得到妥善处理。他们现在最糟糕的情况是一个小时。正确的。现在这是更糟糕的情况，它是最大的组成部分，在它被分解之后。它们最大的组成部分大约需要一个小时。 So, you know, for us that’s, what, a 93 percent improvement in performance. For us, if you think about how we look at this, right, we’re trying to basically make our developers just as productive as we can. We want them spending as much time as the keyboard writing code as they possibly can and we just dropped the cycle time, right, for those people by 93 percent or better.

我们在那个环境中运行的一些组件现在只需要一分半钟就能在构建环境中构建好，这意味着，我们现在有了一个更加敏捷的方法来做事。它是，你知道，构建一点，测试一点，你知道，构建一点，测试一点-在非常紧张的时间框架内完成这些工作。这对我们来说是一个很大的改变。

复制构建结果的最初时间，特别是使用这个，它生成了大约12g的图像，大约花了400分钟从主构建者那里把它吸回来，穿过广域网，传到本地站点人们想要做一些现场测试。现在我们有了可以在本地构建的东西并通过本地网络进行传输，我们将时间缩短到大约12分钟。正确的。再一次，从循环时间的角度来看，在性能方面有很大的不同。实际上，它甚至比这更好，因为我们正在与Artifactory一起做的一些新东西，现在正在发布，我们认为我们可以把这些事情缩短到几分钟。那是因为那里已经有一堆藏物了。这将是最糟糕的情况，大小的工件，是我们唯一需要担心的当我们开始把东西拉过来的时候因为其他的东西都已经准备好了。

原始同步源的时间大约是10分钟左右。正确的。在新模型中，我们在最糟糕的情况下只剩下30秒。所以，你知道，你再次看到了大约95%的改善在循环时间和性能方面。然后是最后一个。特征分支的概念。在此之前，我们花了大约48小时来手动配置和设置一个功能分支，并让它运行起来。我们现在只需要12个，所以，你知道，这已经好了75%了，但还是很多。事实证明，其中11个半小时是合格的，对吧。这是在我们启动它，让它运行，一切正常之后我们基本上投入了回归套件以确保它能工作，这花了11个半小时。 So that one we’re still working on cause we got to cram it down a bit more.

对我们来说，我们已经做了四年了。你知道，我们已经开始转向敏捷和类似的事情。我们花了18个月的时间来研究这个谜题。并开始从中看到巨大的红利。我们现在开始采用完全相同的模式，并开始在更广泛的组织中推广。我们得到了中心的功能，不好意思，功能现在插入了一些较小的。让证明案例得到验证，然后开始与我们的IT团队合作，将所有内容复制到边缘。

所以当我们继续研究的时候，这个很重要。所以，我再说一次，我们经常通过收购来发展。我们每年进行两到三次收购并不罕见。我们过去是这样做的，你知道，我们把他们带进来，他们有自己的IT，他们有自己的工具链，他们有自己做所有这些事情的方式，从开发的角度来看，我们过去很难让他们融入我们的组织。所以现在我们发现的是一套相关的工具，我们现在在中心部分使用，以及在几分钟内打开辐条的能力，而不是几周或几个月之类的东西。我们发现，就我们消化新公司进入的能力而言，这要容易得多，我们能够将他们纳入我们的工具链，获得标准化，并以我们公司的规模获得回报。

我想这就是主要的内容。我想留点时间，我想最后我还有10分钟。