专家试图解释DevOps并几乎成功

什么是DevOps？它与软件开发中的其他思想和方法有何关系？Linux Journal副编辑兼长期软件开发人员Bryan Lunduke不确定，因此他请一些专家帮助他更好地了解DevOps现象。

DevOps 这个词使我感到困惑。

我什至不确定每次说出这个词时，我对我所经历的痛苦（就在我的大脑中部）的确感到困惑吗？

我并不是不喜欢DevOps；那是我真的不明白它实际上是什么。让我示范一下。以下是维基百科上DevOps的定义：

DevOps是一组软件开发实践，结合了软件开发（Dev）和信息技术操作（Ops）来缩短系统开发生命周期，同时频繁提供功能，修复和更新，以与业务目标保持一致。

我很确定仅通过复制和粘贴该语句就可以获得三个动脉瘤，而我仍然不知道DevOps到底是什么。也许我应该备份一下，并给出一些背景信息。

我的职业生涯始于1990年代，当时我获得了软件测试工程师的第一份工作（希望在软件发布之前就可以发现软件错误并告知程序员的人们）。在随后的几年中，随着我尽力完成尽可能多的软件行业职位，我的头衔和职责逐渐发展：

• 自动化工程师：自动化测试软件的人员。

• 测试中的软件开发工程师：为测试人员使用的工具。

• 软件开发工程师：又名“编码员”，又名“程序员”。

• 开发人员主管：“嘿，您是一个优秀的程序员！您还应该管理其他一些程序员，但仍然像以前一样编写代码，但是，不用担心，我们不会给您带来太大的收获！太好了！”

• 开发经理：像开发负责人一样，更少的编程，更多的管理。

• 工程总监：程序员经理的经理。

• 技术/工程副总裁：又名“大老板书呆子，他会做出决定，如果错过最后期限，就会首先遇到麻烦。”

在我获得花式裤子冠军的各种时间里，我管理着以下团队：

• SysOps：曾经代表“系统操作员”，该人运行和维护可访问网络的系统，但现在已被重新定义为“系统操作”，其定义完全混乱，似乎没有人同意。

• SysAdmins：又名“系统管理员”，与SysOps类似，只是较新。

• 项目经理：记录项目需求并帮助工程师，测试人员和团队中其他人员进行工作的人员。

所有这些都说了很长的路要走：“我应该知道DevOps到底意味着什么。”

但是我没有。我真的，真的不是。也许是我的大脑有缺陷。也许我只是来自计算机行业的不同时代，当时使用了不同的词语和想法。而且，显然，我并不孤单。如果您在Google中搜索“ define DevOps”，则会获得超过4,300万个结果。我已经点击了大约4,200万个（尽管我是通过DuckDuckGo进行搜索的），并且进一步了解了这个术语的含义。

幸运的是，我能够结识一些以某种方式在DevOps中工作的漂亮的聪明人。因此，我向他们提出了一个简单的挑战：

“向我解释DevOps的含义。不使用任何流行语就可以加分。”

接下来的几个星期中，与四位“ DevOps专家”进行了精彩的对话。为了使所有人都能轻松地进行跟踪，我已经将这些对话的关键部分进行了编辑，并与一位奇异的DevOps专家一起将它们编辑为一个半真实，半虚幻的聊天，这是所有这四个因素的结合。

我们称他为“ Ted”。

注意：在进行过程中，将使用一些读者可能不熟悉的软件工程术语。发生这种情况时，我已经包含了定义。

伦杜克：好的，特德。什么是DevOps？

特德： Wikipedia将DevOps定义为“结合了软件开发的一组软件开发实践”。

伦杜克：哇！一定要在那里阻止你。我已经阅读了维基百科条目。我已阅读文章和各种DevOps年度报告。我去参加了会议，并观看了带有滑动面板的演示文稿，其中充满了嗡嗡声，足以使我的头旋转。用你自己的话给我

泰德：幸运的是，DevOps是一个简单的想法。让开发人员和运营人员融合在一起。

伦杜克：我想我们不是在谈论公司内部的传统“运营”（供应链之类的东西）吗？首席运营官之类的？

泰德：不，更多的系统操作。SysAdmin工作。

伦杜克：哦，好吧。那么是与SysAdmins合作的开发人员吗？

Ted：和QA（测试人员）—参与软件开发生命周期的每个人都通力合作以实现持续集成和更快的发布。

伦杜克：听起来像敏捷。同样，短语“持续集成”使人难以忍受，几乎等同于“增强公司协同作用”。

维基百科对敏捷软件开发的定义如下：

敏捷软件开发是一种软件开发方法，在此方法下，需求和解决方案通过自组织和跨职能团队以及他们的客户/最终用户的协作来发展。它提倡适应性计划，渐进式发展，及早交付和持续改进，并鼓励对变化做出快速而灵活的反应。

泰德：我知道，这是一个糟糕的名词，但是这个主意仍然是个好主意。至于像敏捷一样，有一些相似之处，但是重点是不同的。敏捷的意义在于使工程团队与项目经理和客户的合作更加轻松快捷，而DevOps则是使工程团队与处理项目所需的所有IT基础架构的人员（例如sysadmins）紧密合作。

Lunduke：所以，我听到的是DevOps是一种“系统管理员和工程师应该交谈”的说法。但是那不可能。自从吉米·卡特（Jimmy Carter）担任总统以来一直存在的想法太简单（而且很明显）了（尽管实际上并不总是付诸行动）。不仅限于此。否则，将不会有专门针对DevOps的整个会议和公司。

泰德（Ted）：许多想法和最佳实践围绕着DevOps演变而来，以帮助团队取得成功，但这确实是基本想法。有时，在寻求将Dev与Ops更好地集成的过程中，两者完全融合为同一时间甚至同一角色。

Lunduke：那是一个非常简单的想法（并且在大多数计算机具有GUI之前就已经存在）。为什么需要一个新名词？当我经营自己的企业时，我既戴开发帽，也戴系统管理员帽。从技术上讲，这让我成为了DevOps ...回想起来？

特德：是的。技术上！但是不要对这个术语太挂了。重要的部分是有助于实现该想法的想法和最佳实践。可以将其简单地视为一组想法和工具，以帮助软件在开发和生产环境中正常运行。这也是一种强制工程师可以维护他们产生的代码的方式。

伦杜克：我认为当我在这里寻找新的东西时，我的大脑中的电路会跳闸。从您所描述的内容来看，DevOps似乎是一个基本概念（或一小部分想法），存在时间比当今大多数工作人员活着的时间更长。也许如果您能给我一个关于DevOps-y最佳实践的例子，那将帮助我解决这个问题。

泰德：当然。一种显而易见的最佳实践是发布较小的，增量的和频繁的更改。工程师，测试人员和管理员（或DevOps工程师）一起工作，可以迅速发布微小的更改。这使得每个发行版的风险和错误发生几率都降低了。而且它可以更快地为用户带来改进（即使是较小的改进）。

Lunduke：冒着烦人的风险（我知道，为时已晚），这听起来完全像敏捷开发。参与生产的每个人都在同一个团队中（或非常紧密地合作），以快速地发布小的迭代更新。

泰德（Ted）：除非它比敏捷更快，否则可能会更快。它肯定比瀑布快。

Wikipedia定义软件开发的瀑布模型如下：

瀑布模型是将项目活动分解为线性顺序阶段的过程，其中每个阶段都取决于前一个阶段的可交付成果，并且对应于特定的任务。在软件开发中，它往往是迭代性和灵活性较差的方法之一，因为在概念，启动，分析，设计，构造，测试，部署和维护的各个阶段中，进展主要沿一个方向（如瀑布般“向下”）流动。

Lunduke：但是从技术上讲，敏捷对发布的频率没有任何限制。如果愿意，您可以每天（每小时，每小时）执行一次敏捷Sprint。

这是Sprint的维基百科定义：

冲刺（或迭代）是Scrum（敏捷开发中通常使用的框架）中开发的基本单元。冲刺是有时间限制的工作；也就是说，它被限制为特定的持续时间。每次冲刺的持续时间是预先确定的，通常在一周到一个月之间，最常见的是两周。

泰德：关于敏捷与DevOps的争论将持续很多年。幸运的是，DevOps的核心思想是有用的。交流的一系列最佳实践（在书籍，会议和其他方面）确实对工程团队很有帮助。

伦杜克：我的意思是，我想我明白了。（对我而言）听起来仍然像敏捷。嘿，泰德，你能帮我个忙吗？

泰德：嘿，当然，伦杜克。

Lunduke：您能以某种方式将DevOps与Linux结合吗？您知道，这对Linux Journal和其他所有文章都有什么影响。

泰德：嗯，我认识的大多数DevOps用户都运行Linux，尤其是在服务器端。这算吗？

伦杜克：是的，是的。

Bryan Lunduke是前软件测试员，前程序员，前技术副总裁，前Linux市场专家（tm），前openSUSE董事会成员...，现任Linux Journal副编辑，Purism营销总监以及该书的主持人流行的Lunduke表演。更多详细信息：http : //lunduke.com。