从手工集成到持续集成

小张是一名软件工程专业的学生，毕业后进入到了一家初创的互联网公司从事后端开发的的工作。每天的任务就是开发产品经理提出的需求。

手工集成

在产品启动阶段，上线不是很频繁小张每天开发需求完成后就打包代码，然后登陆服务器把打包的jar包（java项目运行一般会被打包为jar,war）通过FTP或者使用scp命令上传到服

务器。每天发布代码是小张最开心的事，因为发布完成后就可以下班啦。

脚本集成

随着向前的项目推进，开发人员越来越多并且软件交付质量越来越低，项目经理要求大家每开发完一个需求就要更新到测试服务器以检验完成的功能的是否合乎需求。小张就按照一往的操作编译、跑单元测试、发布到测试服务器，只是一往这些做完都表示着即将下班。随着发布的日渐频繁小张发现每次集成都占据着自己不小的时间。随后小张开始思考，作为一名软件工程的使命就是提高世界的生产效率如果自己每天都对这些大量重复，无脑的体力活不进行自动化，那么作为一名软件工程师是非常不合格的。

小张看到自己每天集成都是在执行如下几个命令mvn,ssh,scp，java，那么可以把这几个命令写成一个脚本就可以完成自动集成了。

来看脚本集成的脚本

持续集成

随着产品的上线的成功，越来越多的用户使用小张公司的产品，随着而来的就是软件的压力骤然上升，服务器的数量也由之前的一台逐步上都几十台。小张还在沾沾自喜自己之前把手动集成变成脚本集成提升了集成的效率，但是项目经理老王已经发现了脚本集成的一些问题。

集成出现问题没有反馈机制：集成失败没有发送邮件或者消息到工作群，导致多台服务器只有一部分正常，实际线上产品只用到了部分正常的服务器，导致服务器资源浪费。

忘记集成：在需求很多任务很多的时候小张和他的同事完成需求后会忘记执行集成脚本。

不可视化：不能统计目前集成的失败情况及每次的集成的日志

扩展性差：新增新的通知目标都要增加脚本，并且shell只能完成一些简单的脚本任务等等一系列的问题。

老王告诉小张，鉴于上次引入脚本集成不错的表现，让小张去了解一下自动集成的工具jenkins，把它引入到我们的项目中来，我们效果不错的话再推广到公司其他项目。

小张非常开心，因为可以探索新的东西学习到最新的理念，下班回家后，小张立马开启了海绵模式。经过几天的学习和实施，小张顺利引入了jenkins到项目中。

来看我的jenkins专栏了解更多知识。(https://blog.csdn.net/column/details/17438.html)