Hi!
在开始这个话题之前,我们来回忆一下在日常的开发发布的时候经常会出现的情况: 在产品上线前夕,也是很多公司最繁忙的时候。已经凌晨了,办公室内仍然热火朝天。测试同学不断的喊着某个开发同学的名字,这里是怎么了?怎么不好用了,之前不是好好的?jira上的Bug列表如泉涌般出现了各种各样的问题。研发同学焦头烂额,不断的去查看一个又一个bug。好的情况是终于搞定了所有问题,抬起木木的脑袋(都感觉不到是自己的了)看向窗外,东方已经泛起了鱼肚白,又是一个不眠之夜。不断的解决这些问题,攻城拔寨,终于能保证如期上线了,想想还有点成就感呢。但凡是也有例外,坏的情况是最终也没有解决完问题,尤其是有那么一些疑难杂症,项目上线只好延期。
面对领导的诘问,只能说:开发完在开发环境(或app模拟器)测试时完全正常的啊。。。。
这是经常会出现的场景,我们按部就班的在测试环境中开发产品,测试在测试环境中测试,到最后到了最后阶段,要上线了,环境变了,各种问题都出现了。要么是设备和模拟器的差异造成的,要么是某个参数设置有问题等等。
总而言之,这样传统的工作方式有以下问题:
而持续集成就是为了防止这种事情的发生。
在软件工程中,持续集成(CI)是指将所有开发者的工作副本每天多次合并到主干的做法。Grady Booch 在1991年的 Booch method 中首次命名并提出了 CI 的概念,尽管在当时他并不主张每天多次集成。而 XP(Extreme programming,极限编程)采用了 CI 的概念,并提倡每天不止一次集成。
To use, see:Jektify - Doc
Goodbye!
Put a very powerful message.