云原生时代（二）：DevOps与CI/CD

上文我们主要介绍了云原生的由来、定义及CNCF基金会，第二部分我们来讲DevOps与CI/CD。

---

DevOps

DevOps（Development & Operations，开发和运维）是09年提出来的概念，但一直没有太火。直到14年，容器与微服务架构的提出，DevOps才得到了快速的发展。DevOps不单是一个实现自动化的工具链，而是组织、流程与技术的结合。组织上强调全栈团队、团队特性专一、团队自治；技术上打通开发与运维；流程上强调端到端、可视化、灰度升级、A/B测试等。

对于DevOps，微服务不是必须的，但微服务为DevOps提供了最好的架构支撑，对于组织和流程的要求也是一致的。所以，也有人称微服务是DevOps架构。

DevOps流程示意图

DevOps与下面提到的CI、CD不同，DevOps更偏向于一种对于文化氛围的构建。DevOps也即是促使开发人员与运维人员之间相互协作的文化。DevOps的概念似乎与持续交付的概念有些类似，两者均旨在促进开发与运维之间的协作，但是实际上两者差别很大：DevOps 更偏向于一种文化的构建，在DevOps文化指导下，团队中将包含了具有不同技能的人员（开发、测试等），并通过自动化测试与发布的手段，更快、更高质量的生产软件。

---

持续集成

持续集成（CONTINUOUS INTEGRATION，CI）指的是开发人员频繁的（一天多次的）将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证，以保障所有的提交在合并主干之后的质量问题，对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。

持续集成流程示意图

持续集成带来的好处是：

• 易于定位错误

• 易于控制开发流程

• 易于Code Review

• 易于减少不必要的工作

---

持续交付

与持续集成相比，持续交付（CONTINUOUS DELIVERY，CD）的侧重点在于交付，其核心对象不在于代码，而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。与持续集成相比较，持续交付添加了测试Test->模拟Staging->生产Production的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。

持续交付流程示意图

持续交付带来的好处是：

• 繁琐的部署工作没有了。团队不再需要花费几天的时间去准备一个发布

• 可以更快的进行交付，这样就加快了与客户之间的反馈环

• 轻松应对小变更，加速迭代

---

持续部署

持续部署（CONTINUOUS DEPLOYMENT）指的是通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比，持续部署强调了通过自动部署的手段，对新的软件功能进行集成。同持续交付相比持续集成的区别体现在对生产的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。

持续部署流程示意图

持续部署带来的好处是：

• 发布频率更快，因为不需要停下来等待发布。每一处提交都会自动触发发布流

• 在小批量发布的时候，风险降低了，发现问题可以很轻松的修复

• 客户每天都可以看到持续改进和提升，而不是每个月或者每季度，或者每年

自动实时的部署上线，是最优的解决办法，但持续部署的要求是团队非常成熟，并且上线前是需要经过QA测试的，所以实际情况下很难实现，一般的团队也很难接受，挑战和风险都很大。

我们总结下，DevOps、持续集成、持续交付、持续部署并不是某种技术栈或者框架，而是开发文化、流程、理念和操作方式。下一部分，我们将介绍云原生最重要的概念之一：微服务。

下一期内容为《云原生时代（三）：微服务、API管理与集成》

参考文档：

本文的部分内容参考或者引用以下文章，在此表示感谢，如果有涉及知识产权的问题，请联系我及时修改。

微服务架构

持续集成、持续交付、持续部署