持续集成
开发中，我们经常遇到一些奇怪的问题，比如本地可以编译成功的代码但是同事们更新代码后编译出错，或者在项目有多个target的时候，资源文件只添加到了当前的target，另外一个target这个时候是不能正常编译的，再比如写的工具类，被同事改了，或者自己有所改动很多地方用到了，怎么保证这个类的行为没有发生变化而影响到项目中的其他模块呢？诸如此类
那么这些问题原因在哪呢，可否避免呢？当然是可以避免的，如果代码有新的改动，提交到版本库中的时候，有一个人帮我们检查必要事项，然后做做测试不就好了，这个当然是可以的，前提是老板同意专门招一个这样的人。
引起各种奇怪问题的原因有很多，比如开发环境比较复杂不干净，IDE的bug，提交前有一些必要的检查需要做，但是开发时因为各种原因没做，这些机械重复的事情我们可以找一个工具来帮我们做，而且这个工具跑在一个专门的服务器上，该服务器环境相对干净，可以运行一些自动化操作，而自动编译，代码检查，测试等环节，那么这种东西，解释接下来讲的持续集成。
持续集成是什么？
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能发生很多次集成，每次的集成都通过自动化的构建(包括编译，发布，自动化测试)来验证，从而尽早发现集成错误，简单来说，就是持续的定时的再多个团队成员的工作中进行集成，并且给予反馈。
持续集成需要开发人员一天多次的将代码集成到主干，并进行自动化编译，测试等操作，由于这种频繁集成，以及集成后及时开始的编译和测试，可以有效避免我们在提交代码时没有进行必要检查而导致的错误，以及一些超出预期效果的更改，从而保证代码的质量。
由于这种及时性，如果在一次提交后项目集成失败，可以快速的在这次提交中查找问题所在，缩小了找问题的范围，从而减少了一些debug的时间。同时如果按照这种实践，那么我们的主干代码时刻都是正确的，这样我们可以更频繁的交付。
为什么要用持续集成？
一般规模较小的项目，对外部系统的依赖和服务调用很小，对于软件的集成不是问题，但是随着软件复杂度的增加，对集成提成了更多的要求，持续集成的好处就提现出来了。
- 对重复的编译发布等操作进行抽象，减少重复过程。
- 及时发现各种冲突和错误，减少风险。
- 任何时间，任何地点生成可部署的软件
- 开发人员和运维人员都减轻了工作负担
持续集成怎么做？
基本要求：要将这种实践付诸实际，需要一些必备的条件，如下：
- 一个自动构建过程，包括自动编译、分发、部署和测试等。
- 一个代码仓库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程中的其中一个素材。
- 一个持续集成服务器。
自动化构建过程，可帮助我们节省大量时间，完成这个过程的自动化后，在以后的开发中，我们需要做的，只是提交代码到版本库中，构建自动完成，基本不再需要人工干预。
代码仓库作为构建的素材库，构建所需的代码从代码库中获得。
最好有一台服务器单独作为持续集成服务器，一方面保证了环境的纯净，一方面不影响开发，而且持续集成服务器一般都是随时准备开始构建的，所以一般也不会关机。
首先要有统一的代码库，持续集成服务器按一定频率(或者使用钩子)从版本控制服务器(代码库)上检查代码是否有更新。如果发现有代码更新，那么就从版本控制服务器上下载最新的代码，等代码完全更新以后，调用自动化比编译脚本(maven项目下的pom.xml文件)，进行代码编译。然后运行所有的自动化测试，并且进行代码分析。如果其中任何一个步骤失败，就表示build失败，持续集成服务器会给予响应的反馈。每次提交代码之后，都会在持续集成服务器上触发一个定时构建，然后进行编译部署。
大致的流程图，便于理解：
测试环境：
- 开发人员将代码上传至Git服务器
- Jenkins持续集成服务器拉取Git上的代码并配合maven将项目自动构建成war包或jar包
- 通过shell脚本自动发布项目到测试服务器
生产环境：
测试环境将项目测试没问题后，将项目推送到线上正式环境。关于自动推送到线上环境又有一套严密的流程。
备注：有时候我们在测试环境经过仔细的测试后没问题后推送到线上环境，但是依然会出现问题，有时是测试问题，有时是无法完全模拟线上环境问题(调用第三方需要认证的接口除外，如支付接口等)，那么这时候我们就可以考虑上docker了。保证了环境的一致性的同时又可以做到完整的镜像版本迭代。
