持续集成

首先是 WiKi 给出的定义:

continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

持续集成 的含义为:频繁的(一天多次的)将所有开发者的工作合并到主干上。

以图例说明持续集成的流程:

从图例上来看持续集成的流程就十分清晰了:

开发人员提交代码到 Source Repository (源代码仓库),并通过 git hook 等

触发 CI Server(持续集成服务器)的相关功能。执行 编译 -> 测试 -> 输出结果 的流程,

向开发人员反馈结果的 report

可以看出,持续集成的 核心 在于 确保新增的代码能够与原先代码正确的集成。与后续要介绍的持续交付以及持续部署,其最主要的差别也就在于其目标不同。

不过持续集成的流程还存在一定的异议:上图所示的流程为 Build -> Test,在阮老师的教程里头是 Test -> Build。不过,持续集成本身只不过是一种软件工程的方法或者策略,其并不规定具体的实现。在实际的应用中,还是需要结合具体的开发语言或者工具来定。

持续集成的优势

和我们一直在使用的 阶段集成(完成一个阶段的开发后执行代码的集成) 相比, 持续集成 的策略能够为我们带来哪些好处呢?

易于定位错误:每一次的代码集成都需要执行相关的测试工作,持续集成频繁的集成次数天然的将复杂的代码逻辑切割为了小块,也就使得每一次测试中遇到的错误能够更加容易的被定位;

易于控制开发流程:更为细致的工作提交也就意味着更容易判断当前的工作进度,这对于管理者规划开发流程而言提供了一个有效的参考,同时也为开发人员省下了汇报工作的时间;

易于CodeReview:对于大块工作的切分自然也有助于做 CodeReview;

易于减少不必要的工作:build 以及 test 过程的自动化可以为你节约一大票的时间,从而投入到有价值的工作中去。

持续交付

同样,以 WiKi 的定义开头:

Continuous delivery (CD or CDE) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually.

持续交付 指的是:一种能够使得软件在较短的循环中可靠的发布的软件工程方法。

与持续集成相比,持续交付的侧重点在于 交付,其核心对象不在于代码,而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试,其变动到持续交付后还需要一些额外的流程。

仍然以图例说明:

可以看到,与 持续集成 相比较,持续交付 添加了 Test -> Staging -> Production 的流程,也就是为新增的代码添加了一个保证: 确保新增的代码在生产环境中是可用的 。

在这一增加的流程中,Test 环节不仅仅包含基本的单元测试,还需要延伸到更为复杂的功能测试以及集成测试等。在这里,Staging 指的是 类生产环境 ,其尽可能的对真实的网络拓扑、数据库数据以及硬件设备等资源进行模拟,从而为测试人员反馈代码在生成环境中的可能表现。流程中每一个环节的执行结果都会对开发人员进行反馈,每一个出现的错误都会导致版本的回滚。当测试完毕确认无误之后,将由相关人员对其进行 手动部署到生产环境。

持续部署

照惯例 Wiki 开头:

Continuous deployment (CD) is a software engineering approach in which software functionalities are delivered frequently through automated deployments.

持续部署 意味着:通过自动化部署的手段将软件功能频繁的进行交付。

与持续交付以及持续集成相比,持续部署强调了通过 automated deployment 的手段,对新的软件功能进行集成。

上图例说明:

可以看到,同 持续交付 相比 持续集成 的区别体现在对 Production 的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预,完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度,保证新的功能能够第一时间部署到生产环境并被使用。

DevOps

介绍完了持续集成、持续交付和持续部署三大件,接下来在讲讲 DevOps。与三大件不同,DevOps 更偏向于一种对于文化氛围的构建。

还是搬出 Wiki:

DevOps (a clipped compound of “development” and “operations”) is a software development methodology that combines software development (Dev) with information technology operations (Ops). The goal of DevOps is to shorten the systems development life cycle while also delivering features, fixes, and updates frequently in close alignment with business objectives.

DevOps 一词本身是对于 development 以及 operation 两个词的混合,其目的在于缩短系统开发的生命周期,在这过程中发布特性、修复bug以及更新均被紧密的结合。

听起来似乎有点玄乎,可以这样理解:DevOps 也即是促使开发人员与运维人员之间相互协作的文化。

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

以图为例:

在传统的团队组织方式中,开发人员与运维人员之间是割裂开的,软件开发流程被分割为多个独立环节,分别由不同的人员执行。这使得软件开发过程中需要付出高昂的沟通成本,层层手动的流程将大量的时间耗费在了重复的劳动中。

在 DevOps 的指导下,不同技能的人员处在同个团队中,为了一个共同的软件开发目标而工作,更好的协同工作与自动化的手段能够优化整个 Code -> Build -> Test -> Release -> Operate -> Code 的循环。这一理念看起来很美,用图画来说明就构成了一个和谐友好的大圈,不过在实际应用中也许会遇到不少问题,例如不同技能人员之间相互沟通的额外开销、团队组织形式改变后为管理所带来的困难等等。这些问题大概等到真正将 DevOps 在开发过程中开展来才能做解答了。

总结

我对于 持续集成、 持续交付 和 持续部署 三者的理解是:

持续集成 是三者中最简单的,同时也是开销最低的。由于不需要类生产环境的配合,测试环境也可以仅支持单元测试的执行,使得持续集成的实现是最为便宜的。考虑到现实开发过程的种种限制,向资源与成本做妥协,舍弃持续交付或者持续部署这样看起来很美的方法,退而转向持续集成也是很合理的选择;

持续交付 面向开发初期或者软件稳定性或者安全性要求较高的领域,新增代码提交、编译、测试等一系列环节均可以通过自动化工具完成,很好的节约了人力资源的同时,还对新增代码的功能进行了有效的保障。在手动执行的部署环节,还可以添加在执行完毕标准测试之外的可能需求,以保证发布功能的可靠;

持续部署 面向稳定的发布上线后的功能更新。自动的,无需人工干预的部署可以保证新增功能第一时间被发布到生产环境中,确保其尽快的被用户所使用。其与持续交付相比,就在于其功能可靠性与功能及时性的侧重不同。

那么,在哪里能买得到呢? 该怎么对这些方法进行使用呢?

这就需要相关工具的配合协作了,以前端开发为例:

持续集成的工具有:Travis CI、Circle CI、jenkins 等

测试框架有:jasmine、mocha 等

测试运行器有:karma 等

构建工具有:grunt、gulp 等

balabala…