产品经理人的持续交付和DevOps实践
如果你正处于下列情形中 ，那这篇文章是为你准备的：
-
你目前身处技术行业，你是产品经理，并且，你明白特性分支是什么，CD代表什么，DevOps文化是什么样子的。
-
或者，你已经在实施敏捷，团队每周都会与您的产品人员会面，讨论故事和迭代。他们合作良好，他们此时构建的感觉比以往任何时候都要好。但是您的客户仍然不能更快地获取这些功能，你依旧要要等待版本发布后才能使用。你可能已经听说过像Etsy，Flickr和Google这样的公司，他们每天交付100次，但他们是如何做到的呢？
-
又或者，你的开发团队想要实现CI/CD，并且你也听说了一些美好的事情，你依旧关心期间的一些变数。那么CD到底是什么呢？
让我们从一些定义和例子开始吧。
Continuous Integration (CI)，持续集成
在传统的软件开发过程中，整合过程通常在每个人完成工作后，在项目结束时进行。 整合通常需要数周或数月时间，很可能也会非常痛苦。持续集成是将整合阶段提前到开发周期的一种做法，以便构建，测试和集成代码更经常地发生。
持续集成意味着在不同的团队成员间在不同的环境中分别为相同的产品编写软件，并将它们的更改集成在一个称为源码仓库库的地方。针各自编写的零碎代码构建组合成一个整体的软件，并按照他们期望的方式工作。
开发人员经常采用一个被称做持续集成服务器的工具为他们做构建和集成的工作。持续集成要求团队成员必须有可以自测的代码，这些代码可以验证代码如预期版的正常工作，这些测试被称做单元测试。当代码集成后所有的代码单元测试通过，团队将会得到一个成功的构建结果。这表明他们验证过了各自的变更被成功的集成到一起，同时代码如测试时预期的一样工作着。虽然集成后的代码成功的在一起正常工作，但它没有准备好上生产环境，因为它还没有在模拟生产环境中进行测试和验证。你可以在下面的连续交付部分中阅读更多关于持续集成之后发生的情况。
图1
为了保持正确的持续集成实践，团队成员的代码变更必须经常提交到主要的源代码库，并频繁地集成和测试他们的代码。通常是一小时多次，但至少每天一次。CI的好处是使整合成为非必要的事件。软件一直处于被编码和集成中。在CI之前，整合发生在创建过程的最后，只一次发生，并且花费了不确定的时间; 现在有了CI，每天都会发生，并且仅需要几分钟。
Continuous Delivery (CD)，持续交付
我们回到我们的开发团队，持续交付意味着每次对代码进行更改时，都会集成和构建代码，以便在与生产非常相似的环境中自动测试此代码。通常，部署管道环境具有开发环境、测试环境和模拟生产环境，但这些阶段因团队、产品和组织而异。 例如，我们的Mingle团队有一个叫做“Cupcake”的阶段，它是一个模拟生产环境，而Etsy的模拟环境被称为“Princess”。
图2
在每个不同的环境中，编码写的代码测试结果不同。这个过程对业务来说是非常有力的。 这意味着，如果单元测试通过了所有的环境验证，那么你知道代码在生产环境时很可能也会正常工作。 一旦测试在所有环境中通过，您就可以立即决定您的最终用户是否获得最新的功能。而且，一旦您的开发人员完成构建，就可以随时为客户提供全新的、经过全面测试的工作软件。
Continuous Deployment(CD)，持续部署
图3
从上图可以清晰的看出，要实现持续部署，首先需要持续交付。持续交付的前提在CI的基础之上，但最终是否应用到生产环境中去，还是通过手动的方式来进行，持续部署真正实现了全自动部署更新发布。
DevOps
“DevOps”一词来自“开发”和“操作”一词的组合。 DevOps是一种促进开发人员和其他技术专业人士之间的合作的文化，具体来说，在软件交付和部署过程中的沟通和协作，目标是更快速，更可靠地发布更好的质量软件。具有所谓DevOps文化的组织的共同特点是：自主多才技术团队，高水平的测试和发布自动化（持续交付）和共同目标多面手成员。
传统方式的软件交付过程如下：
图4
采用持续交付部署路线后，演变成以下的方式，见下图。
图5
DevOps文化通常与持续交付相关联，因为它们旨在增加开发人员和运营团队之间的协作，并且使用自动流程来更快速、频繁、可靠地构建、测试和发布软件。
题外话：此文是SUZIE PRINCE发布在mindtheproduct网站上的文章，第一次尝试着意译过来，便于大家初识敏捷开发、持续部署及Devops之道，第一次翻译难免有疏漏，还望各位见凉，点击原文即可英文原版文章。
成长的乐趣，在于分享!
|
