CI(持续集成)——I

这一篇文章是作为开场白简单说一下个人对持续集成的一点认识，也算是为下一篇介绍具体的实现方案做个铺垫，不足之处还望指正。

CI概念

CI和CD(持续部署)一般是一起出现的，个人理解，持续集成就是为持续部署服务的，原来的开发模式可以总结成下面的图(画工比较烂)

像上图，一个项目开始，开发人员开发自测完成后交由运维部署，然后测试，发现bug之后就会重复执行这一过程，这一过程的缺点如下：

• Bug总是在最后才出现。
• 程序经常需要变更，手动集成十分频繁，会耗费很多时间，尤其是当前软件开发需要产品快速产出，使用原来开发流程的不足就显得更加明显
• 无效的等待变多，浪费大量时间，开发在等待集成其他人的模块，测试人员在等待开发修复Bug，产品经理在等待新版本上线给客户做演示，项目经理在等待其他人提交代码。
  基于上述问题，CI应运而生：
  在软件工程中，持续集成（CI）是指将所有开发者的工作副本每天多次合并到主干的做法。
  使用CI的好处：
• 解放了重复性劳动。自动化集成可以解放集成等重复性劳动，而借助机器集成的效明显比手工高很多，从而实现高频次的持续集成
• 更快地修复问题。持续集成可以更早的获取变更，更快进入测试，从而更早的发现问题
• 减少人工频繁操作造成的失误。一旦需要执行的重复性操作过多，人工手动操作难免就会出现错误，而对机器而言，只要告诉它怎么做就OK了，出错的几率极小
• 减少了等待时间。采用持续集成缩短了软件开发各个环节的时间，从而也就缩短了中间可以出现的等待时机。换句话说，使用持续集成就意味着开发、集成、测试、部署等各个开发环节也得以持续。
• 更快完成产品交付。正因为使用持续集成可以减少各个开发环节的等待时间，所以可以保证产品的尽快交付与产品迭代
• 更高的产品质量。一方面持续集成服务器可以提供代码规范检查等功能，可以保证代码质量，另一方面，因为节约时间成本，就可以将更多的注意力放在提高产品质量上

实践

• 可以实现代码频繁提交，一种方式是使用gitlab内置GitLab-CI搭配Runner实现(会在下一篇讲到)，当代码完成推送时会自动进行集成
• 集成过程可视化，通过上述方式实现持续集成，使得集成结果可视化，通过命令窗口可以看到集成的每一个过程与最终结果，并且可以通过配置，将失败结果发送给相关人员
• 更早的发现集成错误，在集成服务器上执行构建的过程中，就可以及早发现已经存在的集成错误

by Relon