本文共 2842 字，大约阅读时间需要 9 分钟。

其实，这是一篇跟自动化有关的文章。无论是持续集成，还是持续交付、持续部署，还有DevOps，都跟自动化密切相关。

一、什么是持续集成？

持续集成（Continuous integration，简称CI）。就是持续地提交代码。提交自己的代码，集成到团队的代码中。

持续集成的好处是：

1）快速发现问题 每完成一点更新，就集成到主干，可以快速发现问题，定位错误也比较容易。团队开发中，也更容易看到集体的劳动成果，反映项目的最新进度。

通常，持续集成机制还会辅之以自动化测试。不过，依我看，就算没有这个机制，光靠人工将项目跑起来，也能起到尽早发现问题的效果。

2）防止分支大幅度偏离主干，造成集成困难甚至无法集成。

将主干称为主库可能更合适。关于这点，用过GIT估计感触最深了。做过开发都知道，如果多人一起开发，如果你长时间没有提交、获取代码，那么等到集成的时候，代码冲突的机会就越大。

持续集成是一种软件开发实践，通常每个成员每天至少集成一次。

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

与持续集成相对应的概念，还有持续交付和持续部署。

持续交付（Continuous delivery），频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入部署阶段。比如可以将程序手动地部署到生产环境

持续部署（continuous deployment），代码通过评审以后，自动部署到生产环境。持续部署的前提是能自动化完成测试、构建、部署等步骤。

acceptance test：验收测试

三、不同阶段的运行环境

开发环境和生产（production）环境不必多言，在这两种环境之间还有许多环境。这些环境的复杂程度，介于开发环境和生产环境之间。

1）QA环境

顾名思义这是进行功能测试的环境，功能测试多半是手工方式，测试者也未必只是QA们。这个环境通常和产品环境具有一定的相似度，会部署一些真实的第三方应用。有时候也会兼用作演示(showcase)环境，抑或将演示环境独立出来。

2）Staging环境

预发布环境。和生产环境极度相似，可以理解为生产环境的克隆。相同的服务器系统，配置，网络环境，拓扑结构，以及程序相同的部署方法。QA只有在staging server上对新版本做最后一轮确认（verification）, 通过后才能部署到产品线上。

staging，有分期之意，在这里指持续交付。

其实，对一个应用系统而言，开发正常，部署出问题，最常见的原因是数据库不同，其他的似乎都挺虚。我很好奇，这个所谓的Staging环境，用的是哪里的数据库？直接用生产环境的数据库是最理想的，不过如果有很多增删改查就不好办了。

3）E2E测试环境

这个E2E测试是个什么鬼？其实就是End-to-End，端对端测试，意思就是站在用户角度进行测试，看是否实现了用户的需求。应该就是确认/验收测试了吧。什么将程序看成一个黑箱子，这不就是黑盒子测试了吗？功能测试都是黑盒子测试啊。单元测试才算白盒子测试。

这破玩意说的挺玄乎：

那么E2E测试环境为啥还介于staging测试环境和生产环境之间？意思是真正部署之前，还要部署到客户的某台机上，让他们确认一下？不懂。从层级看，这个E2E测试环境好像才是传说中的预发布环境。

四、持续与敏捷

持续，切香肠似的，每次一小片，持续，增量，迭代，这跟敏捷开发中的小步快进、持续交付是相通的。只不过，持续集成交付部署里，多了一个要素，就是自动化而已。

五、DevOps

按百度百科的定义是这样的：

**DevOps（Development和Operations的组合词）**是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。

就是说，DevOps说的是开发和运维要互相配合，紧密合作。Dev就是开发人员，Ops就是运维人员。

但是，都知道要紧密合作，问题是怎么合作法？不可能，只是口头说一说，强调一下精诚团结的重要性就自然而然地紧密合作了吧？怎么样才能让这个DevOps落地才是最重要的。

答案还是自动化。

开发阶段的测试可以是自动化，交付的程序也可以自动化部署。

按照以前，部署一个系统并不十分复杂，吭哧吭哧开发、测试完，照着部署说明手工做就行了。但现在系统规模越来越大，架构由单体变成微服务，每个服务独立开发，独立部署，独立配置，并且采用技术栈、涉及的系统环境可能都不一样，部署工作越来越复杂。这时候，如果还依靠手工一个个部署，按部就班，工作量大，又容易出错。

现在都是这么玩的：

部署一些机器，专门用来管理代码，进行上线工作，由运维事先把上线的规则都给定义好了，开发只要按照规则都访问这台服务器进行各自的代码合成和发布，最后就自己上线了。能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西。

运维需要做的事情，慢慢的都沉淀到了各个平台上面，例如监控，有专门的监控组件和可视化，基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，日志也有专门的日志工具，链路追踪也有专门的组件和可视化，还有网关等，渐渐的，只要这些都配置好了，开发也可以做运维的部分工作，毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，于是DEVOPS开发模式诞生了，开发也是运维。开发运维一体化。

DevOps是现在最炙手可热的方法和技术，目标是能够以可持续的方式，将变更快速、安全的部署到生产环境或用户手中，让软件交付过程可以做到持续交付，实现更短的交付周期、更高质量和更低的成本。

从下图可以看出，开发、测试、运维重合部分就是DevOps，意思就是，开发、测试、运维都是这批人。敏捷开发有一种方法叫scrum，其中有一个最佳实践（？）就是多职能团队，意思是团队里的人，角色并不十分明显，每个人可以做的工作是多方面的。跟这里的DevOps也是相通的。

六、总结

云原生系统的四大特征：微服务、容器化、持续交付和DevOps，本文就涉及到了其中2个。这两个，都要以自动化作为基础才可持续。又由上可知，持续交付、DevOps与敏捷开发有许多共同之处。自动化、敏捷开发，小步快进，持续反馈，归根到底，都是为了提高软件的生产效率，降低系统开发成本。互联网时代，一切都要快，快速试错，快速出成果，仿佛在与时间赛跑。在快的同时，信息系统的规模还比以往更大，数据更多，于是又有了微服务将复杂问题分解为多个简单小问题。

所以说，云原生，敏捷开发，是业界发展的产物。

转载地址：https://leftfist.blog.csdn.net/article/details/115018379 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！