用例——作为持续交付工具链主干的人工制品

讨论转录:

谢谢大家今天下午的光临。我叫克雷格·沃斯伯格。我在CA技术公司工作。我在CTO的办公室工作，在公司工作了7年。通过收购，你会发现我们的许多公司就是这样进入CA的。我个人的背景是，我做软件开发已经超过25年了。我大概一半是在管理方面，一半是在技术方面的个人贡献者。我现在以个人贡献者的身份回来为CTO工作，围绕我今天要讲的内容做一些事情。围绕着公司内部的工具转型之类的事情。在此之前的工作是在我们的一个业务部门进行周转，我们有一个特定的产品，我将使用它作为我们经历这个的例子之一。

所以我想我应该敞开心扉，做好准备，对吧。因为我们可能和其他一些人不太一样，我们不是，你知道，我们是中型到大型的。我把东西扔在这里。所以我想在环境方面为我们搭建一个舞台，这类的东西。

所以。首先:谁是CA Technologies，我们在哪里?我们公司大约有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.

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

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

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

所以很多人看了这张幻灯片会说，天哪，这是一个很复杂的过程。所以我想说的是，我们把这个当作背景。所以这不是为了过程而过程。我们基本上是从这些东西中挑选出能解决我们问题的部分。对于我们的一些较小的总线，当你进入投资组合管理和类似的东西时，他们没有这些上层的东西。但是我们的一些大的公共汽车，他们花了很多时间在上面试图弄清楚他们将如何把钱投资到蛋糕上。这只是一个背景。这就是我们对敏捷和扩展敏捷的看法。我们沿着这条路走下去，最初，我们打算尝试自己建立这个过程。经过几年的时间，我们发现，这是一项很大的工作。 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华体会最新官方网站比如我们去年收购的Rally产品。这是一种开发模式，他们每天都发布产品。我们还有其他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个人一起做测试所以这就变成了长杆，对吧。当我们在做这件事的时候试图减少它的后端。

我们没有完成的定义。所以当你开始转向敏捷时，你就开始被DOD之类的东西缠住了。这些人在拍摄这个快照的时候已经采用了敏捷，但是他们做的是，他们读了这本书，然后好吧，我们要把它扔掉，把它放在一起。他们没有做很多让敏捷在这个模型中成功的事情。完成的定义是他们还没有完成的事情之一。所以他们基本上是在冲刺中工作，但他们只是在准备好的时候把代码扔进去。他们没有任何正式的晋升程序。

没有代码覆盖，对吧。我非常相信监督与平衡，对吧，我对完成的定义是我希望团队能够执行的。然后我希望在工具链中有一些东西可以给我一个健全的检查，就代码质量是什么以及是否遵循了这些东西而言。

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

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

就像我已经提到的，没有功能隔离。我们的技能不匹配。我在这里讲这个，这就是全部，当我们深入到这里的展示时。所有这些更多的是关于工具和过程，以及我们如何使用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 Enterprise。特别是在GitHub企业版之后，与其他各种各样的工具相反，因为我们想要的是，第一:社交编码的整个概念。正确的。我们想弄清楚，我们是如何开始将这一点融入公司内部的。 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更多的是草根类的东西。我对编辑所采取的方法就像对编辑的信仰一样。正确的。你会讨论，Vi更好，Emacs更好，Eclipse更好，答案是，我不想争论这些，对吧。我想让你从CI的角度找出什么是最适合你的答案是我们想让你在这个环境中发挥作用。所以我们采取了非常开放的方式。我们开始看到更多的特拉维斯，这类东西开始出现了。但是，你知道，两个主要的，我可能会说，你知道，60% - 70%的人现在在TeamCity上，然后剩下的，你知道，在Jenkins上，其他工具上的比例很小。

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

接下来的两个，CA敏捷中心和Flowdock。敏捷中心是我们为Rally重新命名的名称，所以这是我们进行计划和缺陷跟踪等工作的地方。它是一个基于SaaS的解决方案，所以我们使用它就像我们的客户在基于SaaS的产品中使用它一样。Flowdock，如果你不知道那是什么，如果你熟悉HipChat或Slack，对吧，它是一个ChatOps工具。Flowdock是，它的名气是由几件作品引起的。第一，与Agile Central产品更紧密的集成，这样您就可以在开发人员工作的地方与他们会面。因此，开发人员不必从他们的浏览器或-不好意思-无论他们的ID环境或聊天环境中出来，以便能够为任务或缺陷进行更新，或者发生任何事情，我们试图在他们所在的地方与他们见面。我们把这个功能放到了Flowdocks中，这样他们就可以对Rally产品或CA Agile Central产品进行更新。这样开发商就不用退出了。你还可以从另一个方向整合所有这些工具，对吧，在构建方面，在推广方面，任何类似的东西，所有这些东西都会回流到游戏中。 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%之间。这是我的经验法则，对吧，我们倾向于用在这类事情上。

最后一个我们要讲的是黑鸭。这是我们用于第三方扫描的工具。我们有一个，现在仍然在使用的，内部构建的解决方案来做这些事情。但Black Duck做不到的一件事是，它不能找到头信息没有出现的第三方属性代码。你有一些开发人员，找到一大块代码，说，哦，我喜欢这个，剪切，复制，粘贴，然后放到我的源代码库中。如果这是来自于gpl的东西，对吧，答案是你刚刚阻碍了你的代码。正确的。而这些真的很难找到。正确的。很容易找到有版权标题之类的东西。 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产品来说，在构建过程中产生的安装材料通常是几ghth华体会最新官方网站b，比如20 gb。如果你必须把它拉回你的本地站点，对吧，答案是它真的可以被禁止。人们做的第一件事是，哦，好吧，我们可以自己解决这个问题，我们做一个影子IT，我们把一个小开发者栏放到一个服务器盒子里在某人的开发者桌面下面，我们继续在本地构建。

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

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

我们肯定想要一些东西可以在必要时复制这些文物。让它变得简单。这绝对是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环境，因为这就是我们使用它作为解决方案的方式。我们运行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就是标准的Jenkins。我们实际上用的是现成的詹金斯。今天早上那位先生谈到了一些最好的做法，我发现自己对我们的战争创伤和经验教训点了点头，当我们经历它的时候。对于我们来说，我们基本上提取了基本的Jenkins图像，我们添加了一些额外的插件，特别是我们想要在每个这些网站上都有，然后我们基本上检查了它。

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

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

下一个，这里有个东西叫Git Cache。所以我们发现我们需要一个Git的CDN。但是Git没有这样的功能。正确的。所以我们需要一种机制，能够将源复制到边缘，并使其保持只读缓存的最新状态，这样我们就可以允许人们进行克隆。主要是建造者在高频率地做这些克隆，但如果开发人员需要一个大的工作空间，他们可以使用相同的东西。我们在这里建立了CentOS 7映像，它位于它的基础上，你基本上把Git，只是标准的Git，放在上面，所以现在我们有了一个能够管理环境的机制。

你进入中间那个部分，叫做RepoSync这是我们写的一个小NodeJS应用。我们的计划是将其开源。正确的。这样其他人就可以利用它了。我恰好是GitHub客户顾问委员会的成员，所以我们正试图找到其他对这个功能感兴趣的人。所以我们要把这个放到外面。

这个东西的作用基本上是监听网钩，然后它会施展一点魔法。所以我们试着-回到那个前提，试图在我们放入的边缘节点上有零配置-这个东西的所有配置实际上都在GitHub中发生。所以你进入GitHub，你说，我想复制一个给定的工作空间，通过放入一个web hook，并将它指向这个hub的地址或这个spoke的地址。一旦你放进去并点击保存，它就会发出一个ping。那个ping请求被这个消耗掉，然后它转回来，说，给我那个repo的所有信息。

它要做的第一件事是克隆这个repo，然后把它拉下来放到本地机器上。然后它会转过来，找出谁是所有有权访问这个仓库的用户，他们的隐私是什么。然后它找出这些用户拥有的SSH密钥并复制所有这些内容并将它们放到本地机器上。然后，web钩子使其保持最新状态。正确的。如果有人进来修改了SSH密钥或者有人进来修改了一段代码或者拉出一个请求之类的，web hook会触发这个东西会自动把信息拉回来。它可以在几秒钟内保持同步。正确的。你知道，这不是一个双面提交，所以不是你把它放到主存储库中，然后它就会立即关闭，但即使在我们缓慢的链接上，你知道，通常它的秒数是你得到的，就传播更改所需的时间而言一旦你得到了最初的克隆。

技术方面，这只是一个正在运行的小NodeJS应用。我们之所以选择Node，是因为它是多线程的，而且在它内部建立restful接口来消费东西很简单。当它这样做的时候，它使用Apache和GitoLite。

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

GitoLite是一个现成的产品，它是开源的。它所做的是管理所有的访问权限针对你拥有的一组SSH密钥，针对回购。所以这意味着所有的魔法都能够确保当事情发生时适当的特权被保留，所有这些都被委托给GitoLite，因为它为我们处理这些。

所以，你知道，经过几周的工作，我们最终得到了一个有效的缓存，现在它运行-它是只读的-它在边缘运行，允许我们的人让我们的建设者在那里能够直接从10g网络上的本地数据中提取数据。你可以想象这在性能上有很大的不同，对吧?根据他们的构建时间和类似的东西。我们一会儿会讲到一些数字。

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

谈谈Artifactory因为它仍然只是基于Artifactory，对吧。我们开始使用越来越多的功能。所以我们有了这种轮辐式架构，我们现在已经把一大块大块的代码分解成各种各样的仓库。我们现在有不同的网站拥有他们的拼图他们以他们需要的频率转动它，对吧。构建是在一天的过程中不断进行的，但如果他们想要发布一个新版本，那么每天都要获得一次资格认证，这很好。如果他们想一周做一次，那很好。如果一个月一次，也可以。正确的。我们的想法不是试图对每个人都发号施令，告诉他们如何工作，而是提供一组接口，让我们彼此隔离。这就是Artifactory为我们提供的粘合剂。

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

我们还没有在NodeJS功能方面做太多的工作。正确的。NodeJS需要Bower或NPM。进去一看，里面果然有。正确的。我们使用的是CentOS环境，所以我们的存储库是基于YUM的。所有这些东西，如果你把它们从外部网络中拉出来，你会减慢所有的构建时间，对吧。现在我们把它放在Artifactory中这样它就为我们缓存了所有这些东西。今天早上关于建立repos的最佳实践的评论，对于Docker来说，你有一个开发环境和一个prod，所以你要在两者之间推广两个独立的repos。和我们的模型一样。 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作为我们的仓库因为我们有一个测试这些东西的机制。我们相信这将是一件相对直接的事情。为了能够设置或多或少的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分钟把它从主构建者那里吸回来，回到WAN，到本地站点人们想要做一些现场测试。现在我们有了可以在本地构建并通过本地网络传输的东西，我们将时间缩短到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分钟。