用例- DevOps @ Research & Artifactory

讨论转录:

谢谢你来参加今天的最后一个演讲。我会注意到我们有聚会，所以我们要准时举行。

这次演讲是关于在一个稍有不同的环境中应用DevOps。我的名字是Christian Vecchiola，我对云计算和开发运营感兴趣。更重要的是，这两件事如何让我们做新的和有趣的事情。

我在IBM的澳大利亚研究实验室工作。这是IBM遍布全球的研究实验室家族中最年轻的成员之一。研究不仅仅局限于这些地方，事实上，我们曾经说过，世界就是我们的实验室。这意味着我们去任何需要研究贡献的地方。我们感兴趣的是将项目发展到全球，并对实际应用产生影响。

所以总的来说，我们在IBM的研究基本上是整个公司的前灯。照亮未来。了解什么会是新的突破，并最终发明出下一个大发明。下一个革命性的东西。

你们有些人可能会问，好吧，我们并不是在研发部门开发产品和应用。hth华体会最新官方网站我们做实验工作。那么，我们为什么要关心DevOps呢?开发运营在这幅图景中处于什么位置，为什么我们应该在这方面投入精力?事实证明，至少在我的实验室里，人们在研究上付出了相当大的努力。在软件工程领域。主要是为了使我们通过应用程序和服务所做的一切都能在研究界之外被访问和公开。为此，我们得快点。我们需要能够很快地推出新的原型，新的更新到我们的项目。我们需要能够在不同阶段之间快速迭代，并且我们需要以一种聪明的方式做到这一点。

这是我们实验室里的一个典型场景。不仅仅是在我们的实验室。所以有人有一个想法，或者遇到一个客户问题，需要不同的思考。一般来说，这就是引发研究和调查的原因，了解我们如何以更好的方式解决问题。无论什么问题会[…]一旦研究团队形成了我们应该如何做某事的想法，这就是发展开始的地方。通过大量的咖啡和测试，我们最终得到了我们的第一个原型，我们可以在内部使用，也可以探索我们自己的研究和理解。然后，这个循环可以重复很多次，直到我们对可以展示和使用的产品感到满意。最终我们会回到绘图板上做更多的迭代。

那么开发运营在这方面有什么帮助呢?第一。它帮助我们更快地运行模型。在环境中进行实验，我们可以根据需要提供实验完成后我们可以提供。有时我们需要进行大量的计算，所以能够在手边提供大型环境是一件非常方便的事情。它帮助我们更快速、更可靠地部署。我们希望能够从循环中删除人为错误。但更重要的是，它可以帮助我们自动化很多事情，这样我们就可以真正专注于真正重要的事情和[…]我们自己。这就是研究工作。显然，我们并没有在一夜之间实现大量生产管道的自动化。

事实上，我想说，我们的旅程很漫长。我的实验室在2011年成立，那时我们，就像我们说的，在寻找基础设施。当实验室开放时，我们只有一个本地的小集群，我们只是用来运行不同科学模型的每一个计算。还有很多笔记本电脑。这就是我们的基础设施。当时大多数的项目开发，在最初的4到6个月，都是由研究人员自己的系统管理员和软件工程师来解决的。

在2014年，我们走了一段很长的路，进入了“我将开发ops”的一年。我们有大约90人。所有的研究人员。我们所做的大部分工作都是基于团队的项目。这意味着临时解决方案不再有效，因为它们不可持续。到2014年下半年，作为一个实验室，我们能够为实验室里的每个人建立一个集中的管道。实际上，在IBM的12个实验室中，我们是第一个实现这个目标的实验室。有一个单一的CI管道，可以被我们实验室的所有研究小组使用。

展望今天和今年，我们在每个实验室都有DevOps冠军，他们可以传播文化并实施良好的实践。有的已经有了，有的正在有过程中。我们开始在全球范围内推出研发部门为所有实验室提供的DevOps服务。我们正在做的是，我们开始发展社会编码现象。因此，来自不同实验室的不同研究人员试图尽可能多地利用其他实验室开发的代码、服务和功能。

我们内部使用的工具和平台是什么?从源代码控制开始。从2013年开始，我们开始使用基于Git的系统。2013年，我们在实验室中基于GitLab进行了第一次安装。一年后，Yorktown实验室部署了一个全局GitLab实例。至少在我们的实验室中，源代码控制已经被积极地使用了。到今天为止，我们有超过800个产品的源代码控制。hth华体会最新官方网站我们大约有120到120人，到9月份将增加到150人。我们现在正在向GitHub企业迁移。

在构建服务方面，主要是Jenkins是我们的持续集成工具。我们有多次安装。我们的实验室是2012年开始的，我想甚至在源代码控制之前。现在我们主要在澳大利亚和美国有不同的例子。我们在美国安装的设备占其他实验室的大部分。我们该拿詹金斯怎么办?从本质上讲，我们构建的大多数项目主要是基于Java的构建，基于Node的构建，或基于Python的构建。最近我们开发了很多内部使用的Docker映像。

在工件存储库方面，我们使用JFrog Artifactory。在这五年中，我见证了DevOps链采用的一种非常有趣的模式。通常团队要做的第一件事就是源代码控制。所以这是他们最先使用的DevOps工具。他们希望有一个共享代码的地方。对我们来说，通常是Git。之后，他们开始集成构建服务，这确定了项目的下一个成熟度级别。一旦您固定了源代码控制，固定了构建，您就开始考虑如何利用您构建的不同库和组件，这时您就需要工件管理了。

因此在2013年，在我们的实验室中，我们推出了一个主要用于Java构建的Artifactory实例，大约两年后，一个用于全球实验室的Artifactory实例已经部署在美国。在我们的实验室中，我们主要将它用于Java，但在世界其他地方，Artifactory用作Java的存储库，显然是Node包和Docker映像。

在基础设施管理方面，我们的大部分核心服务都是基于Chef食谱的。我们使用Chef为基础设施生成一个不可更改和可重复的设置。

截至2016年，我们已经将一些核心基础服务编码为Chef recipe，例如许可服务器、监控服务器、Docker注册表和我们内部的Mesos集群。我们大约在一年半前开始了这项工作，我们正在慢慢地替换所有核心服务的大部分安装。我们不会从基于Chef的安装的全球服务中使用这些。

现在，我不想只谈论工具，我想给你们举几个例子，关于我们如何使用所有这些工具来制作一些东西。支持项目开发或内部部署。那么，让我们来看看在将DevOps应用于特定项目时，它们是如何发挥作用的。

这是一个例子。这个项目叫做外科资源优化。本质上它所做的是结合统计建模和数学优化来预测医院在一段时间内对选择性手术的需求。并优化这一需求，以提供更好的分配手术，手术室和病房。现在，我不会谈论它背后的研究细节。今天我想重点讲的是支持这个储备的软件工程工作——这项研究从你写在会议研究论文上的东西变成了人们可以使用和尝试的系统。

这就是开发团队和研究人员每天要做的工作。所以他们通常在当地进行开发。我们所有的项目代码都通过Git进行源代码控制。每当他们提交时，持续集成就会开始，从我们的Artifactory解决方案中获取大部分依赖项，构建，测试软件，运行代码分析，重新部署构建的工件，一些软件指标将进入SonarQube，这让我们了解我们在项目上有多少技术深度，以及需要多少时间来修复它。我们是否对测试有足够的覆盖，或者我们是否应该使用一些其他好的实践，例如，对于Java。

如果构建成功(在大多数情况下是成功的)，我们将自动部署到测试环境中。一个在Bluemix中，一个是我们内部的SoftLayer基础设施。这个过程发生在每次提交时。部署到我们所谓的生产环境，我们用于演示和讨论演示，对我们来说，大约每两个月进行一次测量的发布里程碑，因为我们在发布新特性方面不是非常快。特别是当我们需要对系统所做的研究改进进行编码时。而且，很明显，生产环境是根据Sensu和Kibana的组合进行监控的。所以我们总是能确保在任何给定的时间，我们的系统都是健康的，我们可以展示我们的研究，我不会在晚上接到电话。或者在其他不合适的时候。

我们通过Slack和Redmine的结合来完成大部分项目管理。Slack主要用于未来规划，跟踪bug和问题。对不起。Redmine主要用于未来计划、里程碑、路线图，以及跟踪bug和项目文档。为什么我们使用Slack作为一个工具来讨论项目，进行更多的面对面的讨论让我们聚在一起解决这个问题。我们的一些Slack渠道与构建系统集成在一起。因此，当构建失败时，我们可以将反馈作为通知发送到Slack中。或者当有人提交代码时。Slack有很多额外的插件，你可以插入和配置通道，如果你想集成一些开发操作管道的组件作为你的项目管理和讨论活动的一部分，它非常方便。

另一个使用DevOps管道的项目是测试食谱——使用Jenkins的Chef食谱。因此，我们的服务和系统的大部分Chef食谱都存储在源代码控制中。基本上我们所有的厨师食谱都在那里。每当我们的基础设施和服务团队因为需要升级Jenkins版本而对食谱进行更改时。他们需要编写安装新插件的脚本。发生的事情是提交到源代码控制中，持续集成开始，这本质上是Jenkins作业的过程。我们对配方进行了Ruby验证，以确保没有语法或语义错误。Chef食谱有一个最佳实践的执行者，一旦这两个阶段过去了，我们要做的就是在SoftLayer中自动提供一个[…]机器，这是我们的[…]基础设施。我们在这台机器上自动执行和测试配方，以确保不仅配方在语法和语义上是正确的，而且它也能完成我们期望的任务。如果测试成功通过，我们将提供机器，升级版本，并在下次需要部署任何这些基础设施时将配方用于部署。

我认为这是开发操作管道的一个非常有趣的使用，因为它主要不是为构建软件而设计的，而是用于验证和测试配置管理。

最后，我想总结一下DevOps在过去五年中对我们的意义。它主要是一场文化、过程和工具方面的革命。

这是一场文化革命，因为我们开始更多地分享。我们开始，因为我们分享了更多，我们更被迫测试我们的代码，正确地记录它，我们也开始学习如何自动化-自动化一些部署，并从经验中学习，以便我们下次能做得更好。

这显然要求我们开发一些与构建、测试和部署相关的流程。用于项目管理、自动化和跟踪的迭代，并能够持续重复此过程。

显然，工具很重要，但不是唯一的东西。因此，我们开始在搜索控制、构建环境、工件管理、项目跟踪、配置管理，以及代码覆盖和代码分析方面投入更多的结构和方法，这确实帮助我们提高了我们交付的软件的质量。并确保我们在环境生产中投入的东西不太可能损坏。至少不经常。

这就是我们目前所做的。接下来呢?我期待在未来两年看到什么。我希望在研究社区中看到与社会编码相关的相当大的增长。我期待，我很高兴看到在我们使用的工具链和管道方面的融合有所改善。正如我之前提到的，我们现在正在为整个研究部门推出GitHub Enterprise，这将允许我们，而不是为不同的实验室拥有多个GitLab存储库，拥有一个单一的源代码控制，每个人都可以看到，可以进行Git拉出或分叉一些代码，或更积极地为项目做出贡献，例如，在同一个实验室的另一个实验室或另一个团队正在做的事情。显然，我们将继续学习和练习。正确的。这样，在每一轮比赛中，我们都会做得越来越好。

我差不多已经结束了我的大部分演讲。我可以回答大家的问题，因为我们还有很多时间。