关于持续集成（CI）

什么是持续集成（CI）

持续集成（Continuous integration）是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

为什么需要持续集成

在没有应用持续集成之前，传统的开发模式是这样的：

• 项目一开始是先划分好模块，分配模块给相应的开发人员；
• 开发人员开发好一个模块就进行单元测试；
• 等所有的模块都开发完成之后，由项目经理对所有代码进行集成；
• 集成后的项目由项目经理部署到测试服务器上，被交由测试人员进行集成测试；
• 测试过程中出现 Bug 就提把问题记录进行 Bug 列表中；
• 项目经理分配 Bug 给相应的责任人进行修改；
• 修改完成后，项目经理再次对项目进行集成，并部署到测试服务器上；
• 测试人员在下一次的集成测试中进行回归测试；
• 通过通过之后就部署到生产环境中；
• 如果测试不通过，则重复上述“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工作。

这样的开发模式导致了很多潜在的问题：

1.Bug 总是在最后才发现

2.越到项目后期，问题越难解决

3.软件交付时机无法保障

4.无效的等待变多

5.用户的满足度低

那么为了解决这样的问题，CI应运而生——

怎么样才算是“持续”&如何实现持续集成

1.怎么样去做：对于一天需要集成多少次数，并没有一个明确的定义。一般就是按照自己项目的实际需要来设置一定的频率，少则可能几次，多则可能达几十次。可以设置按照代码的变更来触发集成，或者设置一个固定时间周期来集成，也可以手工点击集成的按钮来“一键集成”。

2.工作流程：

• 当开始更改代码时，开发人员会从代码库（如 SVN、Git 等）获取当前代码库的副本。
• 当其他开发人员将更改的代码提交到代码库时，此副本将逐渐停止反映代码库中的代码。代码分支保持检出的时间越长，当开发人员分支重新集成到主线时，多个集成冲突和故障的风险就越大。
• 当开发人员向代码库提交代码时，他们必须首先更新他们的代码，以反映代码库中的最新更改。
• 当存储库与开发人员的副本不同，他们必须要花时间来先处理冲突。

持续集成的好处

1. 解放了重复性劳动

自动化部署工作可以解放了集成、测试、部署等重复性劳动，而且机器集成的频率明显可以比手工的高很多。

2. 更快地修复问题

由于持续集成更早的获取变更，更早的进入测试，也就能更早的发现问题，解决问题的成本显著下降。

3. 更快地交付成果

及早集成、及早测试减少了缺陷遗留到部署环节的机会。在某些情况下，更早地查找错误还会减少解决错误所需的工作量。

如果集成服务器对代码进行构建过程中发现错误，可以及时发送邮件或者短信提供给开发人员进行修复。

如果集成服务器在部署环节发现当前版本有问题不可用，集成服务器会将部署回退到上一个版本。这样服务器上始终都会有一个可用的版本。

4. 减少手工的错误

人与机器的一个最大的区别是，在重复性动作上，人容易犯错，而机器犯错的几率几乎为零。所以，当我们搭建完成集成服务器后，以后的事就交给集成服务器来打理吧。

5. 减少了等待时间

持续集成缩短了从开发、集成、测试、部署各个环节的时间，从而也就缩短了中间可以出现的等待时间。持续集成，意味着开发、集成、测试、部署也得以持续。

6. 更高的产品质量

集成服务器往往提供 Code review、代码质量检测等功能。对代码不规范或者有错误的地方会进行标识，也可以设置邮件、短信等进行告警。而开发人员通过 Code review 也可以持续提高编程的能力

 

原文转载出处：http://www.importnew.com/24358.html

这是一篇写的很好的文章，和大家分享一下。侵权必删。