关于持续集成相关的概念，我是这次参加百人计划才了解到的，原本还想着学习后把公司系统的测试环境部署到Linux下，自己慢慢折腾下，结果问了下开发，因我所在公司开发语言用的是ASP.net，属于老版本，都是在windows环境下部署的，如果用.net core来开发，就可以进行部署了，但是现有的系统得全部重做，对于传统行业来说，安全稳定保守第一（开发说的）。
先普及下概念吧
持续集成Continuous integration：简称CI，指的是频繁地（一天多次）将代码集成到主干，防止分支大幅偏离主干，主要解决以下问题：
1、解放劳动力
所有脚本都写到Jenkins里，可实现一键构建
P.S.有些公司开发自己打包告知测试，这部分人员前途堪忧（只接触到测试中间的功能执行环节，很多流程的都没接触过，知识面过窄），而我是这其中的一员，想要以后混的好一点，必须趁着这2个月好好恶补下，希望能跟上进度。
2、避免人为失误
拷贝包出错、不小心删了某个包、忘记kill进程、文件编辑错误等
3、提交效率
一般流程--包编译、上传、下载、传服务器，耗时会比较久
4、质量持续反馈
每日/时构建，跑自动化，自动触发自动化脚本及监控体系，（版本质量、单元测试、代码规范、接口自动化、核心的GUI），每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。有问题开发已经收到报告，都不需要提交给测试
5、质量保障
实时触发自动化接口，实时知道版本质量
持续集成是针对一个团队的，成员有开发、测试、运维等。一般是质量团队主导，测试团队能力不够可找运维协助（不排除很多成功的测试没有代码能力）。实际上持续集成要落地实施还是会存在很多障碍的，比如QA团队能力不够，没人懂代码，这种情况可以采用内部培养或者外部招聘 。
与持续集成相关的，还有两个概念，分别是持续交付和持续部署。
持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。可以看作持续集成的下一步，它强调的是，不管怎么更新，软件是随时随地可以交付的。
持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
前提：能自动化完成测试、构建、部署等步骤
目标：代码在任何时刻都是可部署的，可以进入生产阶段
持续部署（自动触发）与持续交付（手动触发）的区别，可以参考下图
很明显，持续集成有个必要条件--自动化成熟度非常高
回忆下目前公司项目的流程
1、项目立项，明确需求（开发点、测试点）
2、一系列的评审（设计评审、开发文档评审、测试用例评审等）
3、开发编码，提交测试
4、测试人员开始测试，发现Bug，提交Bug
5、开发修复，重新提交测试
6、测试验证
......
循环几轮后，达到了上线的标准，相信很多人都会遇到开发都没有自测就提交了代码，一些显而易见的bug简单几步操作就被测出来了，有些bug可能还会影响测试的进度。
作为测试人员，希望简单的Bug 能越早发现，留更多的时间去挖掘严重/更深层的Bug，测试理论告诉我们，越早发现Bug，修复Bug的代价也就越低。
那么如何实施呢？
有些代码开发很早就开发完了，但是一直没被测试，如果RD写完部分功能就提交测试，那么测试自然就会提前开始，相对来说能较早的发现Bug。这时就体现出持续集成的优势了，每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
本次课程分享的是用Jenkins作为持续集成工具来实战
Jenkins是基于Java开发的一种持续集成工具，用于监控持续重复的工作。我们可以把Jenkins想象成一个框架，想让它做什么它就能做什么，前提是安装它需要的插件，或者用shell / python手动写脚本。
Jenkins能提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性，用户界面设计的很简单，也比较实用，文档很完善，还有很丰富的插件，比较容易上手。
