翻译: 产品经理持续交付和DevOps指南

翻译：The Product Managers’ Guide to Continuous Delivery and DevOps (产品经理持续交付和DevOps指南)

原文链接：https://www.mindtheproduct.com/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/

相关术语

1. 持续集成(continuous integration，简称CI)
2. 持续交付(continuous delivery，简称CD)
3. 持续部署(continuous deployment)
4. DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
5. Agile Software Development : 敏捷开发。

正文翻译

在这个指南中，我致力于揭开持续交付和DevOps的神秘面纱。我将解释这些实践，告诉您它们对您“在业务方面”有多重要，并帮助您参与其中。这并不复杂，下面用详细的图例说明。

本指南适合您……

• 您拥有技术，您是产品经理或MBA。您的团队需要进行A/B测试，功能特性切换/功能分支（Feature Toggle）和 you have a dog in the office！当然，您了解什么是功能分支，什么是CD以及DevOps文化是什么样的。对？嗯…当然。
• 你以参与敏捷开发了。现在，工程团队每周都会与您的产品人员开会，讨论故事和迭代。他们合作得很好，正在建设的东西比以往任何时候都感觉更好。但是您的客户仍然无法更快地获得这些功能。You still have to wait for the release train to leave the station.（您仍然必须等待释放火车离开车站)。您听说过像Etsy，Flickr和Google这样的公司每天交付100次。他们是如何做到的呢？
• 您的开发团队希望“做CD（持续交付）”。您已经听到了一些好消息，但是，您还会担心在没有进行适当测试或不能正确地将更改推向市场的情况下将更改推向生产环境。CD是指什么？

让我们从一些定义和示例开始：

Continuous Integration (CI) — 持续集成

在传统的软件开发中，整合过程通常在每个人完成工作之后、在项目结束阶段进行。整合过程通常需要数周乃至数月的时间，可能会非常痛苦。持续集成是一种在开发周期的早期阶段进行集成的实践，以便构建、测试、整合代码可以更经常的进行。

CI意味着一个在家里的笔记本上写代码的开发者（比如Steve）和另外一位在办公室桌上写代码的开发人员（比如Annie）可以分别为同一款产品编写软件，将他们的修改合并在一个称为源代码库的地方。然后他们可以从各自编写并合并在一起的代码中构建软件，并测试它是否按照他们期望的方式工作。

开发人员通常使用称为CI服务器的工具来为其构建和集成。CI要求Steve和Annie有能自我测试的代码。这些代码测试自身确保它们能按预期运行。通常这些测试被称为单元测试。在整合代码后，当所有的单元测试通过，Steve和Annie会获得绿色构建版本。这表明他们已经验证他们的更改成功的整合在了一起，并且代码正如测试所预期的那样工作。

不过，尽管集成的代码能成功的工作，但仍然不能投产，因为它还没有在类似生产环境中测试和验证以表明能够工作。

你可以在下面“持续交付”一节中，阅读在完成CI之后的更多信息。

为了实践CI，Steve和Annie必须提交代码到主要的源代码仓库，密集、经常的集成和测试他们的代码。通常每小时多次，但是每天至少一次。

CI的优点在于，整合代码变成了“非事件”（译注：意思是它总在发生，出错也不奇怪）。软件一直在编写和集成。在搞CI以前，代码集成发生在创建过程结束之后，所有整合一次性完成，然后花费的时间未知。现在有了CI，代码集成每天都在发生，只需要花费几分钟的时间。它仅是我们的工作方式。

你的团队很有可能正在搞CI（或者至少他们相信自己正在捣鼓）。你可以通过询问他们是否每天都整合代码来进行确认。CI是进行持续交付所需的第一种实践。事实上，如果你曾经签入过帮助文本、文档或图片，那么你可能已经在一直在不断的集成。

Continuous Delivery (CD) — 持续交付

让我们回到两位开发者Steve和Annie身上。持续交付意味着每次Steve或Annie对代码进行更改、集成和构建时，他们也会在与生产环境非常相似的状态下进行自动的代码测试。我们称这一系列的“部署-测试”到不同环境的操作为部署流水线。通常来说，部署流水线有一个开发环境，一个测试环境，还有一个准生产环境，但是这些阶段因团队，产品和组织各异。例如，我们的Mingle团队有一个称为“蛋糕”的准生产环境，而Etsy的准生产环境叫做“公主”。（译注：消除开发环境和生产环境差异，参考Docker技术体系）

在每个不同的环境中，Annie或Steve写的代码被分别测试。这给了他们越来越多的信心。对你而言，就是代码被部署到生产环境中时，它能够工作。至关重要的是，代码只有在部署流水线中通过了前面的测试，才能提升到下一个测试环境。这样，Annie和Steve可以从每个环境的测试中获得新的反馈。如果出现了错误，他们可以更容易的理解问题到底在哪里，并且在代码进入生产环境之前修复它们。

Continuously Learning — 持续学习

这个过程非常有助于我们的工作。这意味着如果Annie的测试在所有的环境中获得通过，你就可以知道她的代码在生产环境中也应该如同预期一般工作。一旦所有的环境都测试通过，那么你可以立即决定你的用户是否能够获得。我们现在想要这种绿色构建用于生产中么？当然啦！并且，随着你的开发人员完成构建，新的、充分测试的、能工作的软件立马就能提供给客户。爽歪歪！

Continuous Deployment — 持续部署

这是一种实践，即：Steve和Annie所做的每一项变更，在通过所有的测试阶段之后，自动的投入生产环境。Tim Fitz首先提出了一个很好的解释。有些公司这么干，有些则不这样做。想要实现持续部署，首先要实现持续交付。因此在开始实践CD之前，决定哪个更适合你是不重要的。无论哪种方式，我认为持续交付是关于有助于整个业务能力的事情，因此你至少应该参与决定是否使用持续部署。毕竟，如果你正在阅读这篇文章，那么你可能就是在“业务方面”。

DevOps

“DevOps”一词源自“开发-Development”和“运维-Operations”的词汇组合。DevOps是一种促进开发人员（比如Steve和Annie）和其他专业技术人员（如5星级运维明星Joey） – 通常称为运维 – 之间合作的文化。具体来说，就是在软件交付和部署过程中的沟通与协作，旨在更快、更可靠的的发布更高质量的软件。

拥有所谓DevOps文化的组织其共同特征是：自主的具备多种技能的团队（Steve，Annie，Joey都在同一团队），高水平的测试和发布自动化（持续交付）和具有共同目标、有多种技能的团队成员。

你可能会发现在你的组织里可以使用的一种模式是，我们的开发者Steve和Annie将和运维人员比如Joey合作，交付成品软件，而不是仅仅将他们刚完成的代码“交给”Joey去发布。同样的，Steve，Annie和Joey都将作为公共产品或服务团队的一员，他们一起负责产品的支持与维护，而不是让运维团队单独负起支持的责任。

你还会看到行动的自动化对于执行CD和DevOps的组织来说越来越重要。这是因为，为了实现我们期望从CD和DevOps中获得的可重复、定期和成功发布软件的过程，组织必须转向自动化。手工流程很容易出错并且效率低下。

DevOps文化通常与持续交付相关联，因为它们都旨在增加开发人员和运维团队之间的协作，并且都使用自动化流程去更快速、频繁、可靠的构建、测试和发布软件。人们喜欢我们想要的所有这些东西。

下一步是什么?

虽然开发团队经常看到流程改进所带来的立竿见影的好处，但是CI，CD和DevOps对我们其他人来说也有很多好处。简而言之，我相信组织实践CD和拥抱DevOps文化，将能为它们的客户交付更有价值、更为可靠的软件，而且更频繁。这是不是很赞，对吧？特别是如果你在“商业方面”（更多的客户信赖，更多的订单）。

下次我会继续讨论更多为什么你应该关心这些概念。我将讨论它对你的业务的影响以及如何介入。如果你有任何问题，请在评论中与我交流。这些内容的要点就是告知你、赋予你有关与业务相关的技术实践信息。问题很棒，欢迎提问！

Useful Terminology — 常用的术语

Checking in — 签入/检入

将本地开发的代码变更推送到通用代码仓库的过程。（译注：也称为Commit，提交）

CI server — 持续集成服务器

用于构建和测试源代码的工具。CI服务器会告诉开发人员他们最新的代码构建是否成功，以及它们是否继续通过测试。

Development environment — 开发环境

开发人员创建、集成、构建和测试代码的地方。

Deployment pipeline/pipeline — 部署流水线/开发产品线

这是Steve和Annie的代码在完成并准备好交付到生产环境之前，所经历的一系列阶段。通常来说，这些将是“构建、单元测试、功能测试、性能测试、部署”。不同的自动化测试将在不同的阶段运行。只有代码贯穿整个部署流水线，才能将软件交付到生产环境。

Green build — 绿色构建

绿色是成功的标志。绿色版本或构建，是通过测试开发和交付流程的特定阶段的一个版本。一般情况下，一个构建或版本是不会升级到部署流水线的下一个阶段的，除非它是绿色的。绿色构建的反面是红色构建（见下文）

Incremental development — 增量式开发

不要与迭代开发混淆了（见下文）。增量开发是指一次完成一小部分产品的构建，直到全部完成。每次增量中都添加一部分，这些增量可能很小或很大。你可以通过增量开发来使用CI，但是使用增量开发可能难以实现持续交付或持续部署，因为你必须等到所有增量完成之后才能交付价值。解释增量式和迭代式开发之间差异的一个很好例子，是Jeff Paton的蒙娜丽莎。(译注：见下图的说明，意思就是达到目标的不同方式)

增量开发

迭代开发

Integration — 集成

所有由个人或团队编写的代码都需要合并。我们称之为集成。在持续集成中，我们通常指的是来自个体的软件代码需要定期合并。在持续交付中，我们通常指的是来自不同团队的软件集成在一起以创建整个产品。

Iterative development — 迭代开发

不要与增量开发混淆（见上文）。迭代开发是从一点点开始逐次构建产品，不断完善直到完成。产品是迭代开发的，意味着同样的部分每次迭代都要改进。在不同的迭代版本中功能特性有别，在这之间计划和预期产品的变更。你可以使用持续集成、持续交付或持续部署进行迭代开发。Jeff Paton的《蒙娜丽莎》是增量开发和迭代开发之间区别的一个很好的例子。

Master/trunk/mainline — 主要分支

(译注：源代码管理系统中的分支概念，细节可以参考下Git代码管理系统)

“Master/trunk/mainline”是源代码仓库的主要分支，即主线。大多数人都在主干上进行开发，这意味着他们要始终将其变更集成到主线。另一些则在单独的开发人员有自己的分支时，进行基于分支的开发，或者团队将具有不同特性的分支。

Production environment — 生产环境

这是软件部署或发布的地方。使用你的产品或网站的客户最有可能使用此环境。也可以称之为：“在生产中”，“在产品中”，“线上”。

Red build — 红色构建

红色表示失败。红色版本或构建，是指在开发和交付流程中，未通过特定阶段测试的版本。通常，如果软件的的构建是红色的，则不会将其提升到部署流水线的下一个阶段的。红色构建的反面是绿色构建。

Source repository — 源代码库

这是源代码所在的地方。Steve和Annie有他们自己正在上面工作的本地代码版本（意味着代码在他们自己的机器上），但是在开发人员提交修改的代码后，源代码库将包含所有的代码。

Test automation — 自动化测试

持续集成和持续交付需要高质量的自动化测试。测试是检查软件是否按预期工作的方法。自动化测试是代码编写的测试，能够在代码签入公共源代码库后自动运行。

在CI世界中，每次软件集成和构建时都会运行单元测试。如果测试没有通过，那个软件版本就会被确定为不能工作，“红色”，“中断”。在这种情况发生时，有些工作场合会出现“红灯”或者悲伤的声音（提示构建失败）。

如果构建失败了，Steve和Annie（无论谁提交的错误代码）需要修复它，让它变绿色，让它能够工作。他们可以通过修改代码来修复它，或者移除前面造成中断的更改。

Unit tests — 单元测试

单元测试是代码中的自动化测试，通过测试低级、单片的代码以确保它们可用和按预期工作。单元测试被认为是实施CI和CD的先决条件。（译注：单元测试在好多语言、框架里都有很好的支持）

集成、交付、部署理解总结（补充）

来自：https://www.zhihu.com/question/23444990 赵劼

集成是指软件个人研发的部分向软件整体部分交付，以便尽早发现个人开发部分的问题；
部署是代码尽快向可运行的开发/测试节交付，以便尽早测试；
交付是指研发尽快向客户交付，以便尽早发现生产环境中存在的问题。

如果说等到所有东西都完成了才向下个环节交付，导致所有的问题只能再最后才爆发出来，解决成本巨大甚至无法解决。

而所谓的持续，就是说每完成一个完整的部分，就向下个环节交付，发现问题可以马上调整。是的问题不会放大到其他部分和后面的环节。

这种做法的核心思想在于：既然事实上难以做到事先完全了解完整的、正确的需求，那么就干脆一小块一小块的做，并且加快交付的速度和频率，使得交付物尽早在下个环节得到验证。早发现问题早返工。

进一步阅读

• 持续交付：通过构建、测试和部署自动化实现可靠的软件发布
• Martin Fowler关于持续集成的易读指南
• 凤凰项目：一个IT运维的传奇故事
• 持续交付:产品经理的超能力

参考

1. https://www.zhihu.com/question/23444990
2. 给产品经理讲讲，什么是持续交付和DevOps
3. devops （过程、方法与系统的统称）
4. AB测试
5. Feature Toggle - Martin Fowler
6. 互联网敏捷DevOps和自动化之1.DevOps
7. 5 大 DevOps 工具，你用过几个？
8. 26 Hints for Agile Software Development(敏捷开发的26条建议)
9. 敏捷开发之 12条敏捷原则
10. 敏捷软件开发—维基百科

(本文完)