致产品经理： 持续集成、持续交付、持续部署和DevOp

美好的周末又要来临，小数就不跟大家聊沉甸甸的代码了，让我们轻松一下换个话题。今天的主角是产品经理，程序员史蒂夫、安妮和乔伊友情客串，报幕员兼跑龙套就是可爱的小数啦，接下来精彩马上开始——

即使产品经理每周都在与开发团队讨论新功能，团队协作紧密无间，在不断的PUSH下，新功能比以往看起来上线和更新速度快多了。但换个角度，从用户层面，其实仍然是一个缓慢的过程。那对比Flickr 和 Google这样的公司能够现在一天实现100次的更新迭代频率，这到底是怎么做到的呢？

毋庸置疑，这就是通过CI/CD在实际生产环境下带来的好处和便利，作为产品经理， 对于CI/CD概念已经并不陌生，但即使想要通过它们来给现有产品更新带来改变，仍然充满担忧顾虑和担心。 那么下面的内容，将帮助产品经理打消疑虑。

持续集成（Continuous Integration ，CI）

在传统软件开发过程中，集成通常发生在每个人都完成了各自的工作之后。在项目尾声阶段，通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式，让构建、测试和集成代码更经常反复地发生。

持续集成意味着一个在家用笔记本编写代码的开发人员（嘿，史蒂夫）和另一个在办公室编程的开发人员（嘿，安妮）可以为同样的产品分别地编写软件，将其改动整合在一个叫做源存储库的地方。他们可以从各自编写的部分构建出组合的软件，并且按照他们期望的方式来测试软件。

开发人员通常使用一种叫做IC Server 的工具来做构建和集成。持续集成要求史蒂夫和安妮能够自测代码。分别测试各自代码来保证它能够正常工作，这些测试通常被称为单元测试（Unit tests）。

代码集成以后，当所有的单元测试通过，史蒂夫和安妮就得到了一个绿色构建（green build）。这表明他们已经成功地集成在一起，代码正按照测试预期地在工作。然而，尽管集成代码能够成功地一起工作了，它仍未为生产做好准备，因为它没有在类似生产的环境中测试和工作。在下面持续交付部分你可以了解到持续集成后面发生了什么。

考虑到实践持续集成，史蒂夫和安妮必须频繁地登记主代码仓库、集成和测试他们的代码。通常一小时很多次，并且每天最少一次。

持续集成的好处是，集成不再是个头疼事。软件在一直被编写和集成。在持续集成之前，集成发生在创建过程的结尾阶段，一次性完成，并且不知道要耗时多久。而现在持续集成，每天都融入到了工作方式当中。

持续交付（Continuous Delivery，CD）

让我们说回到我们的两位开发人员，史蒂夫和安妮。持续交付意味着每次史蒂夫或安妮修改、整合和构建代码时，也同时在类似于生产环境中自动测试了这段代码。我们通常将这个在不同环境发布和测试的过程叫做部署流水线。通常部署流水线有一个开发环境，一个测试环境，一个准生产环境，但是这些阶段会根据不同的团队、产品和组织而变化。例如，Mingle团队有一个阶段叫做“纸杯蛋糕”的准生产环境，而Etsy的准生产环境叫做“公主”。

在不同的环境下，安妮和史蒂夫写的代码被分别进行测试。当代码部署到生产环境它就开始了工作，这给予了他们更多的信心。并且只有当代码通过前一个环境的测试才会进入到下一个部署流水线的环境当中去。通过这种方式，安妮和史蒂夫将会从每个环境中测试并得到新的反馈，如果有失败，他们也可以在代码被应用到生产环境之前更加容易地发现问题并且修正它。

持续学习

这个过程对于业务决策者来说非常重要。它意味着如果安妮的代码通过了所有环境的测试，并将准备投入生产当中。你需要决定你的用户是否立即能够用上它。我们是否希望这个绿色构建现在投入生产？是的！一旦你的开发者完成了构建，那么一个全新的、充分测试的、可以工作的应用已经为你的用户准备好了。

持续部署（Continuous Deployment）

史蒂夫或者安妮所做的每个改动，都是通过测试环节，然后自动投入生产的实践过程。关于这个概念这个PDF有一个很棒的阐释：（http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf）。 为了达成持续部署，你首先需要持续交付，所以这不是决定哪个优先级更高的二选一。无论如何，持续交付对于业务的决策带来更大的敏捷性，这才是真正实现业务导向的捷径。

开发运维（DevOps）

“DevOps”这个词是“development”和“operations”的组合。DevOps已经上升为一种文化，它促使开发人员（史蒂夫和安妮你们快回来）和其他运维人员协同工作。具体地说，在软件交付和部署的过程中沟通合作，为了能够更快速更可靠地发布质量更好的应用。

拥有DevOps文化的团队通常有一个共同的特征：熟练的多技能团队（史蒂夫，安妮和乔伊都在同一团队里），高水平的测试和自动发布（按持续交付的方式）以及团队成员之间共同的目标。

一种方式是我们的开发朋友史蒂夫和安妮将同运维人员乔伊一起工作将应用交付给生产，而不是只将他们的代码“移交”给乔伊来发布。同样地，史蒂夫、安妮和乔伊都将作为共同负责所有产品支持和维护的服务团体的一部分，而不是仅由运维团队负责支持。

你还将看到自动化的实践对于持续交付和DevOps越来越重要。这是为了从持续交付和DevOps中实现可重复的、固定的和成功的应用发布流程，来避免人工处理非常容易出错、而且效率低下的问题。

DevOps文化通常和持续交付关联起来，因为他们的目标都是为了提升开发团队和运维团队之间的协作效率，都使用自动化进程来更快速、更频繁、更可靠地构建、测试和发布应用。这正是我们想要的。

接下来呢？

产品经理们已经逐步看到持续集成、持续交付和DevOps的诸多好处，那么拥抱DevOps吧，祝大家周末愉快，下周见;)

原文链接：https://wanqu.co/amp/p/2862

转载于:https://blog.51cto.com/h2appy/1865791