前端持续集成之——概念篇

在谈持续集成之前，我们先来回顾一下传统的软件开发模式-瀑布开发模型

在传统软件开发流程中，开发、测试、运维三者是割裂开的，软件开发流程被分割成了多个独立的环节，分别由不同的人员执行。这使得软件开发过程中需要付出高昂的沟通成本，层层手动的流程将大量时间浪费在了重复的任务环节。举个例子：

1. 公司的一个老项目来了个大版本的新需求交给你，确定了需求、交互之后，你开始开活儿了
2. 你和后端把接口文档定义好之后，从 master 上拉了个新分支 feature-xx 开始写代码
3. 你们各自开发用了 20 天，然后你连后端开发的本地电脑开始联调又用了 10 天。这一个月测试同学有可能就在喝茶、聊天、打王者
4. 你们联调完之后，告知测试同学，有测试同学将新分支 feature-xx 部署到测试环境开始测试，又花了 10 天。
5. 测试结束之后，需要将 feature 分支合并到 release 分支部署到预发布环境。由于有其他同学同时在开发这个项目，这时产生了大量的冲突，你不得不和相冲突的同学一起来解决这种问题，这又花了一天的时间。
6. 解决完冲突之后，部署到了预发布环境，这时候又发现新功能中的某些请求在预发环境下各种问题
7. ......
8. 等到所有问题都解决了，才部署上线

我们可以看到，这个开发、测试、部署都是串行的。且新分支由于开发周期长，与主干偏离较大，造成集成困难等问题。

那么持续集成可以为我们带来什么，我们先来了解下几个概念：

持续集成（Continous Integration，简称 CI）

持续集成就是把多个码农写的代码集成到同一个分支，然后经过编译、测试、打包之后将程序保存到 Artifact Repository 里。根据执行结果来尽早的发现问题，保证产品的快速迭代。

持续交付（Continuous delivery，简称CD）

持续交付就是定时地、自动地从 Artifact Repository 将最新的程序部署到测试环境里。它强调的是，不管怎么更新，软件是随时随地可以交付的。

持续部署（continuous deployment）

持续部署就是定时地、自动地将过去一个稳定的发布版本部署到生产环境里。持续部署的前提是能自动化完成测试、构建、部署等步骤。

常见的持续集成工具有以下几种：

Jenkins     
      Jenk