1. 开发人员提交代码到Git版本仓库；
  2. Jenkins人工/定时触发项目构建；
  3. Jenkins拉取代码、代码编码、打包镜像、推送到镜像仓库；
  4. Jenkins将代码或者镜像推送到业务主机。
  5. 前提需要保证软件版本一致

image.png

例子背景描述

假设我们现在有一个产品P，以war包形式发布，由三个模块module A, module B, module C构建而成。三个模块的关系为：A和B为独立模块提供不同功能。C依赖A和B，然后构成产品P。我们使用了Git作为我们代码库的版本管理工具，用Java进行开发，maven作为我们的构建工具。在每个模块里，有我们基于JUnit写的单元测试代码。独立于三个模块外，有一块代码，也是基于JUnit写的，作为我们的功能测试代码（集成测试）。

集成代码

当我们完成开发工作，需要提交代码到代码库前，我们至少需要在本地跑一次单元测试，在保证全部测试通过后，才可以将代码提交至我们的代码库Git上面去。例如，在我们上面描术的项目中，我对module A的代码进行了修改，那我最起码得在本地运行一次mvn test（执行Maven命令，test代表将会执行到maven default生命周期中从validate到test阶段）， 执行成功后，我才会将代码commit and push到远程Git库上去。要做到这样效果的话，就需要保证单元测试代码也同步完成。而在极限编程中（XP），人们比较倾向于测试驱动开发的实践，通过提前写好自动化的单元测试，保证好每一步功能开发的质量。

自动构建

通过CI工具，可以设置一个勾子，当代码提交后触发相应构建。例如，我们提交了module A的代码时，Jenkins会扫描到我们这次提交，勾子触发module A的构建。这个过程会做如下操作：

  1. Jenkins调用Git插件，从Git库上下载最新代码；
  2. Jenkins调用Maven插件，执行Maven命令（一般为mvn install，如果需要上传至远端Maven库，也可以执行mvn deploy）对该模块进行构建。经过编译、通过单元测试后，便可以打包并安装到本地Maven库，以供其它依赖所用。这次构建成功，意味module A在模块自身的单元测试范围内是正常的。

  3. 因为module A是包含在产品P里面，所以，也需要回归一产品功能测试。由于module C依赖A，并构建成产品。所以在CI工具里面，我们需要配置好在module A构建成功后，自动触发module C的构建，经过类似步骤1、2这样的构建后，最终会生成产品P的war包。而C的构建成功，只代表着通过了module C自身的单元测试，还不能对生成的war包进行功能测试。然后就要看我们下一步的工作－－自动部署了。

    自动部署

    在功能测试之前，我们需要在CI工具里配置一项任务，用于将最新构建出来的产品包部署到测试工环境中去。这个任务由产品构建任务成功而被触发，而部署方式根据不同使用方式及不同的实际情况而多种多样。例如通过脚本将新构建的war包上传至指定位置，等待web容器自动扫描及部署。能或者产品有自己的安装脚本，我们在任务中配置好运行安装脚本，就可以自动将产品部署到指定的测试环境中去。

    功能测试（集成测试）

    当部署成功后，真正的功能测试就可以开始了。一般情况下，我们可以独立出一块代码，基于JUnit编写好我们的功能测试代码（JUnit是作为测试的入口以及基本测试框架。如果你的需求比较复杂，那你完全可以将其它三方框架与JUnit集成使用）。功能测试过程和构建过程非常相似，均是依赖Git和Maven去完成：

  4. Jenkins调用Git插件，从Git库上下载最新代码；

  5. Jenkins调用Maven插件，执行Maven命令：mvn clean test。

区别在于功能测试阶段，Maven只执行到default生成周期的test阶段，不会执行后面的package和install。因为它只需要Maven帮忙运行测试代码即可，它本身没有什么可以构建的。
P.S.
如果还需要更复杂的端到端测试的话，可能就需要准备更复杂的部署脚本，或者预先准备好整套端到端测试环境，后面只需要部署好war包即可。但无论怎样，最终原来理还是相同。

交付

当新提交代码后构建出来的产品包，通过了各种各样残酷的测试后，就说明这个包是稳定的，能达到基本交付条件的（前提是自动化测试的覆盖率足够高，当然，有一些极端的情况需要人工测试的另说）。那么，我们就可以将这个包放到指定目录作为交付品，供其它测试团队获取并进行进一步的测试，甚至供生产环境部署使用。