到目前为止，大多数技术人员都熟悉DevOps这个术语。我们称之为“DevOps”的东西在不同的组织之间通常会有所不同，但有一点是一样的：DevOps是由构建软件的人以及他们如何协同工作来定义的，而不仅仅是由他们的工具链中的内容来定义的。
作为GitHub专业服务团队的一员，我有机会了解了许多公司采用DevOps的方式以及团队在日常工作中的表现。以下是我们学到的知识，以及我们在这一过程中遇到的一些常见DevOps误解。
DevOps的定义有很多：一套自动化和集成流程的实践，使团队能够更快、更可靠地构建、测试和发布软件；文化和工具的结合，使组织能够以更高的速度发布软件；文化、运动或哲学。这些都没有错，它们都是DevOps的重要方面，但它们没有完全抓住DevOps核心的东西：Dev和Ops团队之间的基本人为因素，当协作弥合差距，使团队能够更快地交付更好的软件时。
对于组织来说，DevOps通过提高软件质量和稳定性以及缩短生产交付周期来提供价值。对于开发人员来说，DevOps关注自动化和文化——这是关于如何完成工作的。但最重要的是，DevOps让人们能够跨角色协作，快速、安全、可靠地为最终用户提供价值。总之，这是一个焦点、手段和预期结果的组合。
- 这个集中DevOps的核心是人。
- 这个方法实现DevOps的关键是过程和工具。
- 这个结果DevOps是一种更好的产品，交付更快、更可靠。
常见的DevOps神话
一旦我们了解了DevOps是什么，就很容易确定它不是什么，让我们来看看您以前可能听到过的一些误解。
有时我们会听到团队说，“我们使用[tool X]或自动化[X过程]，所以现在我们在做DevOps！”但如上所述，工具和自动化是实现DevOps（手段）的一部分，而不是DevOps本身。这是一项人类协作的努力，我们的工具及其支持的自动化是我们完成这项工作的方式。这个空间里有很多工具；虽然很容易立即采用一组特定的DevOps工具或指定的工具链来缩短您的DevOp旅程，但为您的组织选择合适的工具是您成功的关键。
误解：DevOps是敏捷开发
我们听到的一个最常见的误解是敏捷和DevOps是一样的。虽然很容易混淆这两者，但像敏捷这样的流程是如何进行DevOps的一部分，而不是什么是DevOps。敏捷、精益、极限编程和其他“快速工作、经常发货”的模型只是团队使DevOps成功的众多方法中的一小部分。敏捷可以更快地交付软件，但它不能确保在软件生命周期中与其他团队进行协作，并且如果测试、QA和操作团队处于孤立的组织中，他们可能会被压倒。
误解：DevOps只有一个“正确”版本
实际上，每个组织的DevOps都是不同的，因为每个组织都有自己独特的约束、优势、人才和目标；在一家公司工作的工具和流程不一定会转化为另一家公司的成功。尽管有成功的DevOps转换的常见实践和原则，但它并不是预先打包在一个盒子里的，公司可以通过许多方式成功实现自己的转换。
误解：DevOps只是为了交付价值
虽然DevOps确实为组织提供了价值，帮助他们以速度、稳定性和可靠性开发并向最终用户提供创新，但它还有很多其他的功能。DevOps最初是为了让软件更人性化。通过自动化我们的工作流，人们可以更加关注手头的任务。这给我们的工作带来了更多的乐趣，减少了工作倦怠。
通用DevOps原则
每个成功的DevOps项目都有一些关键概念和原则。将这些与正确的工具、过程和文化相结合将有助于团队找到DevOps的成功。虽然每个组织和团队的DevOps看起来都不同，但以下是一些起始点：
- 共享所有权： 有效合作依靠共享所有权——理解并接受每个人都有责任并以某种方式为工作做出贡献。参与其中的每个人，无论是构建应用程序、维护应用程序，还是以其他身份贡献应用程序，都知道自己与结果息息相关。在DevOps范式中，将工作抛给另一个团队的旧过程被打破了。
- 工作流自动化：自动化实现了一致性、可靠性和效率，使解决问题和错误变得更加容易。通过利用自动化，我们可以帮助避免机构知识的陷阱，只有特定的人知道如何做特定的事情。
- 快速反馈：自动化重复任务（如报告和测试）可以提供快速反馈，以便团队能够快速了解其更改在整个软件生命周期中的影响。这种理解有助于团队更有效地协同工作，因为将更改从编码者传递给构建者、构建者传递给测试者、测试者返回给编码者会产生一个长循环的依赖和阻塞。快速反馈使开发人员和操作团队能够共同做出决策，并基于共享数据实施更改。
组织您的团队进行DevOps
DevOps项目建立在共享原则之上，组织将以不同的方式实施DevOps。
没有一种“完美的方式”比另一种更好地接近DevOps，但有一些倾向和常见的陷阱会使特定的方法比其他方法更具挑战性。
- 公司专用DevOps团队。DevOps工具数量众多、复杂，通常需要专业知识。通过专门指定一个团队来弥合开发和操作之间的差距，您就拥有了一个专门从事这些工具和过程的团队。这种方法的一个挑战是，它又创建了一个竖井，并且是审批的瓶颈。DevOps团队本身并没有打破开发团队和运营团队之间的障碍，而是成为了经纪人。如果DevOps团队规模较小，他们最终可能会成为阻碍者，因为许多团队试图加入并为既定流程做出贡献。
- 每个团队都有专门的DevOps工程师为每个开发团队指派一名DevOps工程师是另一种可能成功的方法。拥有一名跨越特定功能或产品的开发和操作团队的DevOps工程师，有助于为特定任务配备专门的专家。理想情况下，该专家可以指导和支持团队其他成员使用工具和最佳实践。但这种方法也有将此角色视为自动化工作的漏斗的风险，有时甚至会将DevOps工程师变成将代码部署到生产中的唯一看门人。如果不仔细观察团队实践，这可能会变得势不可挡，并导致DevOps工程师精疲力竭，让团队的其他成员无法胜任他们的工作。
- 开发和运营团队。我们看到的第三种方法是让一个团队负责大型应用程序的特定功能子集，其中每个成员负责开发和操作。在这些团队中，通过测试、登台和生产等环境进行部署和升级是开发过程本身的组成部分。这种方法有助于避免其他两种方法的陷阱，但也有更陡峭的学习曲线的额外挑战。当这种方法做得很好时，我们经常看到团队中的专家承担各种责任。团队共同承担总体责任，但个人可以通过挑选符合其兴趣或背景的不同项目来支持团队的其他成员。
DevOps没有单一路径
DevOps从您的员工开始，然后通过构建您团队的文化、目标、优势和约束来付诸实践。了解这些将推动您如何设计特定流程，指导您如何选择DevOps工具，并塑造您采用的DevOps最佳实践，所有这些都将引导您的组织走向自己的成功定义。
没有一种“正确”的方法来实现DevOps。就像技术中的其他一切，以及任何涉及人类的东西一样，DevOps工具和实践都会发生变化。通过将基础架构、应用程序交付和策略作为代码进行标准化和自动化，您可以快速适应，帮助您的团队更快地完成最佳工作，同时保持竞争力。
想了解更多关于DevOps的信息吗？查看具有GitHub操作的DevOpsGitHub学习实验室或我们的DevOps资源综述.
