持续集成之Jenkins插件使用（一）- 多个job之间的串并联

转载自：http://qa.blog.163.com/blog/static/190147002201391661510655/

Jenkins除了开源和免费，还有一个最吸引人的功能之一就是支持插件。

Jenkins不光有丰富的第三方插件，还可以自己动手编写插件，和其他工具进行深度的集成，从而达到符合公司产品管理需求的一个定制化。

接下来我们会分享一系列关于Jenkins插件的使用和开发实践经验，介绍一些经典而又实用的第三方插件和公司内部自己开发的插件，希望大家能在工作中根据项目的需求灵活地运用。

 

这次首先介绍的5个插件都是和Jenkins的job相关的，通过这些插件，可以按需连接各个job，使之协同工作。

 

那开始介绍前，让我们来看看为什么需要这些插件来连接各个job呢。有人可能会说，为什么不能把产品的持续集成步骤统统建立在一个job上呢？

- 首先，Jenkins有一个限制，就是一个job的一次构建的所有任务只能运行在一个节点上，那如果产品的编译/部署/测试需要在不同平台下（如编译必须在Linux下，而执行用例需要在Windows下）就必须建立不同的job

- 再次，如果只有一个job必然构建时间会变长，也就是意味着产品的质量反馈变慢（必须等到所有的任务才做完才能得到反馈）

- 还有，分开建job也是为了相互之间的“弱耦合”，之后相应job的配置改动能尽量小的影响到其他job

- 最后，这样可以使产品的持续集成流程更加清晰，及时发现产品相应的短板

 

 

1. Copy Artifact Plugin

功能介绍：这是个比较简单的插件，只是简单地把某个job的构建物拷贝到当前job的工作区。

简单配置： 

实践应用：

- 在产品被编译/打包之后，需要在测试/联调/演练多个环境下部署的时候，可以采用。一个job负责代码的编译和打包，并把构建物（通常是WAR，JAR，TAR等）存档下来，然后之后的多个job可以分别获取相应的构建物用于产品的部署，保证了部署环境的一致性。

Tips：

+ 一定要保证上游job的构建物是被存档的

 

   

 

+ 默认情况下，拷贝过来的构建物会以相同的目录结构存储，如果只想保留文件而已，可以选择“Flatten directories”，这样所有的构建物都会直接拷贝到“Target directory”，而不会保留目录结构

 

 

2. Parameterized Trigger Plugin

功能介绍：这是一个扩展型的插件，使各个job连接的时候可以传递一些job相关的信息

                     - 当前job的参数

     - 自定义的参数

     - SCM相关信息

     - 运行的Node信息

简单配置：

 

 

实践应用：

- 传递SVN Revision： 在代码检出阶段会获取相应的SVN Revision信息，传递这个信息到下游的job中，在下游的各个job中直接检出相对应版本的代码，保持各个构建的版本一致性，防止由于频繁的代码提交导致各个job运行版本的不一致

- 保持各个job运行在同一个节点下： 如果有多套测试环境，可以通过这个勾选这个选项保持构建环境的一致性

 

Tips：

+ 传递SVN Revision或是GIT Revision可以通过如下设置来完成

   

   在下游job如果需要在SCM管理中使用，可以通过如下设置来配置

 

  

+ 如果不需要传递任何参数，一定要记得勾选“Trigger build without parameters”

 

 

3. Build Pipeline Plugin

功能介绍：这是一个用于生成特定视图的插件，可以把job之间的关联关系可视化，使产品的流程也随之可视化。

简单配置：

 

 

实践应用：

- 在配置产品的持续集成时，往往会有多个job协同工作，比如编译/打包，静态代码检查，单元测试，接口测试，UI测试，性能/压力测试，而各个产品又相互有一定的依赖。通过在这个插件中设置初始job，就能很直观地把job之间的关系整理出来，也能看到产品每次构建的全局情况。在后期还可以从构建信息中挑选合适的版本，增加发布环节。

 

Tips：

+ 通过设置选项“Show pipeline parameters in revision box”可以直观地显示job的build number，结合VersionNumberPlugin就可以显示SVN revision

 

 

+ 通过设置选项“Show pipeline parameters in project headers”可以直观地显示job的某些参数，如测试环境

 

 

4. Multijob Plugin

功能介绍：这是一个集成了ParameterizedTrigger和BuildPipeline的插件，但它是形成一个新的job，而不是一个视图。

                     并且它不要求job之间本身就存在依赖关系。

                     这样一来，建立job的时候可以保持相对的独立性，而通过这个插件来组装成产品所需要的持续集成环境。

简单配置：

 

 

实践应用：

- 如果需要建立多条pipeline，并且在各条pipeline中有些job其实是可以共用的时候，可以考虑使用这个插件。例如产品有两个分支develop和release， 需要分别检出代码（A1，A2），编译（B），单元测试（C），对于develop分支只需进行简单的回归测试（D），而对release分支不仅仅是回归测试（D)，还必须有性能测试（E)。这种情况下，就会有A1-B-C-D和A2-B-C-D-E两条pipeline，对于D来说，下游job是不确定的，这时就可以通过建立两个Multijob来实现（当然，也可以通过PrameterizedTrigger通过设置和读取变量来实现，但是配置较为复杂）

Tips：

+ 在创建job时一定要选择“MultiJob Project”，在“free-style project”下默认是不能选择使用这个插件的

 

 

+ 对于某些job的结果不想影响下游job的执行，例如静态代码检查，可以通过以下设置来达到目的

 

 

 

5. Join Plugin

功能介绍：这也是一个触发job的插件，亮点在于它触发job的条件是等待所有当前job的下游的job都完成才会发生。

                     当然，只有在当前job有两个及以上的下游job时才有意义。                    

                     简单举个例子来说，A同时触发B1和B2两个job，然后配置这个插件又触发C，这时C就会等B1和B2都完成之                          后才会被执行

简单配置：

 

 

 

实践应用：

- 有些产品的部署会依赖于某些第三方的产品，可以同时部署自身的产品和第三方服务，这时接下来的测试工作就需要等待所有这些部署都完成，自然这个插件就能有用武之地

- 为了加快构建的速度，通常可以设置单元测试和冒烟测试同时进行，而随后的功能测试又希望是在单元测试和冒烟测试都通过的情况下才进行，这种情况下Join插件就是必须的了

 

Tips：

+ 默认情况下，通过Join插件触发的job是不能传递参数的，如果有需要，可以勾选“Trigger parameterized build on other project”，这样其实就是把Join插件和ParameterizedTrigger插件集成起来了

 

 

 

小结：上面介绍的这些插件一般情况下不会都使用到，并且某些功能不止一个插件可以实现，所以大家可以根据产品和项目的需求来灵活应用，搭建出可靠、可维护、可视化强的持续集成环境