共计 6031 个字符，预计需要花费 16 分钟才能阅读完成。
持续集成是敏捷领域的一项基本实践，Jenkins 是目前市面上主流的持续集成工具。关于持续集成和 Jenkins 可以讨论的话题很多，本文描述的是一种使用 Jenkins 结合 Maven 进行动态工程构建的思路，用于进行系统开发过程中对第三方服务依赖的解耦。
———————————– 分割线 ———————————–
Linux 下构建 robotium+jenkins+TMTS 可持续集成自动化测试 http://www.linuxidc.com/Linux/2013-06/85633.htm
修改 Ubuntu 下的 jenkins 端口号 http://www.linuxidc.com/Linux/2013-06/85533.htm
Linux 搭建 jenkins http://www.linuxidc.com/Linux/2013-05/84619.htm
jenkins 服务器安装与配置 http://www.linuxidc.com/Linux/2013-05/84615.htm
jenkins 配置基于角色的项目权限管理 http://www.linuxidc.com/Linux/2013-05/84614.htm
Ubuntu Desktop 12.04 LTS 下安装 jenkins http://www.linuxidc.com/Linux/2012-10/72459.htm
用 Jenkins 搭建 Android 自动打包环境 http://www.linuxidc.com/Linux/2014-08/105327.htm
———————————– 分割线 ———————————–
一. 场景
在系统设计和实现过程中，尤其是涉及到多方集成的系统开发，我们经常会遇到这样的场景：即目标系统需要依赖于某些第三方的服务实现，而这些第三方的服务实现通常有其进度安排，会和目标系统平行开发，也就是说在目标系统开发调试过程中，第三方服务往往还无法使用。研发团队无法使用第三方服务，但却需要确认和验证目标系统的相关功能能否正常使用，我们就需要想办法确保在第三方服务不可用的情况下也能获取目标系统的运行过程结果，也就是要对第三方服务进行依赖解耦。这时候模拟（Mock）思想就派上了用场，基于 Mock 思想的系统模型可以抽象为下图：
上图中对于同一个服务契约（Service）而言，第三方服务提供者会提供一份真实环境下的服务实现（ServiceImpl-3rdParty），而我们在模型目标系统运行时会提供一份 Mock 的服务实现（ServiceImpl-Mock）。在第三方服务尚未交付、而我们又想对系统进行开发调试时可以使用 Mock 服务实现；第三方服务一旦就绪，通过简单的开关机制我们又可以切换到 3rdparty 服务。这种场景下的构建需求就是可以通过一定的持续集成手段进行工程的动态构建，也即当我们需要不同的服务实现时，我们就可以构建出不同的服务。
二. 工具和技术
我们假定开发环境基于 JavaEE 平台，Eclipse 工程项目初始化如下。这里虽然局限于某种技术实现平台，但其背后的思路都是一样的：
上图中，mcs-service-3rdparty 和 mcs-service-mock 同时实现了 mcs-service 中的所有服务接口，我们的目标就是要根据本次构建的具体需求（是使用 mock，还是使用 3rdparty），使用 Jenkins 动态的确定这两种实现的一种并完成系统构建。
基于以上目的，我们来看一下具体实现过程中涉及的工具和技术：
1. Jenkins Parameterized Build
Parameterized Build 即参数化构建，是 Jenkins 平台中一项强大的构建功能。通过参数化构建，我们可以在构建过程中为此次构建添加参数，从而灵活控制构建的过程和结果。结合本文中的场景，我们需要在每次构建前告诉 Jenkins 这次构建时需要使用 Mock 的服务实现还是使用 3rdparty 的服务实现，这里我们就可以抽象出一个参数以便进行参数化构建。
2. Maven Profile
我们使用 Maven 进行系统构建的依赖管理和结构组织，参考系统工程项目的组织形式，可以看到我们把 Mock 和 3rdparty 的实现放在同一个主 pom 中，而我们的目标只想在某一个构建中获取两者当中的一个实现。要想使得一个构建不做任何修改就能在两种环境下都能运行，需要使用 Maven 中的 Profile 特性。Profile 实际上就是提供了一种动态选择机制，它为每一种选项定义了一个 Id，在使用 Maven 命令是就可以通过设置该 Id 从而进行构建过程中的动态选择。
三. 具体实践
本节我们从具体的工具入手进行构建的配置和实现：
1. Maven 的 Profile 管理
Maven 中的 Profile 定义方式参考如下：
<profiles>
<profile>
<id>mock</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>com.test</groupId>
<artifactId>mcs-service-mock</artifactId>
</dependency>
</dependencies>
</profile>
<profile>
<id>3rdparty</id>
<dependencies>
<dependency>
<groupId>com.test</groupId>
<artifactId>mcs-service-3rdparty</artifactId>
</dependency>
</dependencies>
</profile>
</profiles>
上面这段配置的意思非常明确，我们定义了两个 Profile 分别对应 Mock 服务和 3rdparty 服务，指定它们的唯一性 Id 为 Mock 和 3rdparty 并关联到具体的 artifact，并通过 activeByDefault 属性确定默认情况下的 Profile 为 mock。
在执行 Maven 命令时，我们可以通过 - P 参数动态设置某一个 Profile，如 -P mock 代表使用 mock 这个 Profile，-P 3rdparty 表示使用 3rdparty 这个 Profile。
更多详情见请继续阅读下一页的精彩内容 ：http://www.linuxidc.com/Linux/2014-11/109834p2.htm
2. Jenkins 参数化构建过程
Jenkins 参数设置需要安装 Jenkins 参数化插件和 Maven 插件，这里不做具体展开。安装完插件之后，我们就可以使用其“参数化构建过程”选择，该选项为我们提供了多种不同类似的参数设置方式，这里我们选择“Choice（多选项）”作为我们的参数类型。基于多选项参数的设置方式如下：
注意上图中参数名为“ServiceImpl”，参数的值范围为 [mock，3rdparty]。参数的值范围需要与上面配置的 Profile 一一对应，而参数名我们在设置 Maven 命令时需要用到：
设置完参数化构建过程之后，平时的”立即构建”按钮就会变成“Build withParameters”，点击构建时就需要我们确定构建选项，效果如下：
通过选择不同的构建参数，我们就能构建出不同的服务，从而动态实现同一套代码和配置完成不同服务构建过程。
四. 小结
本文使用 Jenkins 和持续集成理念为系统开发过程中如何进行第三方服务的依赖解耦提供了一种思路，这种思路基于 Jenkins 的参数化构建功能和 Maven 中的 Profile 特性，在某些特定的场景下非常有用。
持续集成是敏捷领域的一项基本实践，Jenkins 是目前市面上主流的持续集成工具。关于持续集成和 Jenkins 可以讨论的话题很多，本文描述的是一种使用 Jenkins 结合 Maven 进行动态工程构建的思路，用于进行系统开发过程中对第三方服务依赖的解耦。
———————————– 分割线 ———————————–
Linux 下构建 robotium+jenkins+TMTS 可持续集成自动化测试 http://www.linuxidc.com/Linux/2013-06/85633.htm
修改 Ubuntu 下的 jenkins 端口号 http://www.linuxidc.com/Linux/2013-06/85533.htm
Linux 搭建 jenkins http://www.linuxidc.com/Linux/2013-05/84619.htm
jenkins 服务器安装与配置 http://www.linuxidc.com/Linux/2013-05/84615.htm
jenkins 配置基于角色的项目权限管理 http://www.linuxidc.com/Linux/2013-05/84614.htm
Ubuntu Desktop 12.04 LTS 下安装 jenkins http://www.linuxidc.com/Linux/2012-10/72459.htm
用 Jenkins 搭建 Android 自动打包环境 http://www.linuxidc.com/Linux/2014-08/105327.htm
———————————– 分割线 ———————————–
一. 场景
在系统设计和实现过程中，尤其是涉及到多方集成的系统开发，我们经常会遇到这样的场景：即目标系统需要依赖于某些第三方的服务实现，而这些第三方的服务实现通常有其进度安排，会和目标系统平行开发，也就是说在目标系统开发调试过程中，第三方服务往往还无法使用。研发团队无法使用第三方服务，但却需要确认和验证目标系统的相关功能能否正常使用，我们就需要想办法确保在第三方服务不可用的情况下也能获取目标系统的运行过程结果，也就是要对第三方服务进行依赖解耦。这时候模拟（Mock）思想就派上了用场，基于 Mock 思想的系统模型可以抽象为下图：
上图中对于同一个服务契约（Service）而言，第三方服务提供者会提供一份真实环境下的服务实现（ServiceImpl-3rdParty），而我们在模型目标系统运行时会提供一份 Mock 的服务实现（ServiceImpl-Mock）。在第三方服务尚未交付、而我们又想对系统进行开发调试时可以使用 Mock 服务实现；第三方服务一旦就绪，通过简单的开关机制我们又可以切换到 3rdparty 服务。这种场景下的构建需求就是可以通过一定的持续集成手段进行工程的动态构建，也即当我们需要不同的服务实现时，我们就可以构建出不同的服务。
二. 工具和技术
我们假定开发环境基于 JavaEE 平台，Eclipse 工程项目初始化如下。这里虽然局限于某种技术实现平台，但其背后的思路都是一样的：
上图中，mcs-service-3rdparty 和 mcs-service-mock 同时实现了 mcs-service 中的所有服务接口，我们的目标就是要根据本次构建的具体需求（是使用 mock，还是使用 3rdparty），使用 Jenkins 动态的确定这两种实现的一种并完成系统构建。
基于以上目的，我们来看一下具体实现过程中涉及的工具和技术：
1. Jenkins Parameterized Build
Parameterized Build 即参数化构建，是 Jenkins 平台中一项强大的构建功能。通过参数化构建，我们可以在构建过程中为此次构建添加参数，从而灵活控制构建的过程和结果。结合本文中的场景，我们需要在每次构建前告诉 Jenkins 这次构建时需要使用 Mock 的服务实现还是使用 3rdparty 的服务实现，这里我们就可以抽象出一个参数以便进行参数化构建。
2. Maven Profile
我们使用 Maven 进行系统构建的依赖管理和结构组织，参考系统工程项目的组织形式，可以看到我们把 Mock 和 3rdparty 的实现放在同一个主 pom 中，而我们的目标只想在某一个构建中获取两者当中的一个实现。要想使得一个构建不做任何修改就能在两种环境下都能运行，需要使用 Maven 中的 Profile 特性。Profile 实际上就是提供了一种动态选择机制，它为每一种选项定义了一个 Id，在使用 Maven 命令是就可以通过设置该 Id 从而进行构建过程中的动态选择。
三. 具体实践
本节我们从具体的工具入手进行构建的配置和实现：
1. Maven 的 Profile 管理
Maven 中的 Profile 定义方式参考如下：
<profiles>
<profile>
<id>mock</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>com.test</groupId>
<artifactId>mcs-service-mock</artifactId>
</dependency>
</dependencies>
</profile>
<profile>
<id>3rdparty</id>
<dependencies>
<dependency>
<groupId>com.test</groupId>
<artifactId>mcs-service-3rdparty</artifactId>
</dependency>
</dependencies>
</profile>
</profiles>
上面这段配置的意思非常明确，我们定义了两个 Profile 分别对应 Mock 服务和 3rdparty 服务，指定它们的唯一性 Id 为 Mock 和 3rdparty 并关联到具体的 artifact，并通过 activeByDefault 属性确定默认情况下的 Profile 为 mock。
在执行 Maven 命令时，我们可以通过 - P 参数动态设置某一个 Profile，如 -P mock 代表使用 mock 这个 Profile，-P 3rdparty 表示使用 3rdparty 这个 Profile。
更多详情见请继续阅读下一页的精彩内容 ：http://www.linuxidc.com/Linux/2014-11/109834p2.htm
