在《高效研发之——工具篇(4)：Jenkins》中已经介绍了Jenkins策略和配置规划，事实上如果产品/项目本身如果规划统一，合理利用Jenkins提供的参数化构建，可以非常方便地配置测试版本和发布版本任务。
基础规划
1. 每个产品（Product）可以包含多个工程（Project），每个工程生成的war/jar包名与{ProjectName}相同，每个工程都应该创建对应的CI，以实现提交SVN即实时构建，尽早发现并修复代码问题；
2. 每个新增的项目在对应的视图中添加CI，编译参数要包括（checkstyle:checkstyle pmd:pmd findbugs:findbugs clean package -Dmaven.test.skip=true），构建包可生成在ftp://x.x.x.x/incoming/ci/{产品名}/{工程名}；
3. 每个开发人员的每个功能点/任务完成后，都应该立即提交代码；
4. 提测时，项目经理基于要提测的代码，创建branches（如br20171221），并提给测试人员；
5. 测试人员基于该branches构建测试版本包（路径为：ftp://x.x.x.x/incoming/release/{产品名}/{分支号}/{工程名}），并进行测试；
6. 测试通过后，测试人员直接在Jenkins上对当前测试的branches打Tag（如V3.3.1.1222），即发布代码库；
7. 产品经理确定该版本是否发布；
8. 产品经理在Jenkins上基于发布代码库构建版本包，版本包会自动归档在（ftp://x.x.x.x/pub/release/{产品名}/{版本号}/{工程名}）
配置管理
测试/发布版本配置
代码按上述方式统一后，在Jenkins上每个测试/发布版本只需建一个任务，不需要为每个工程新建任务。具体可参考如下：
1. 产品名参数化
产品名参数化
2. Branches/Tags参数化
分支参数化
对于发布版本，此处为Tags路径
3. 工程参数化
注：此处用了个小技巧，即借用List Subversion tags参数化选项来列出本产品的所有工程，所以URL直接指向trunk即可。
工程参数化
4. 生成包类型参数化
由于工程可能生成war或jar包，为方便后续包归档或部署，在此增加ArtifactType的Choice类型参数，
生成包类型参数化
5. 源代码管理
通过使用前面定义的参数，源码库URL基本可以固定为如下形式，每个测试/发布的Jenkins都可以直接复制使用。
源代码配置
6. 生成包管理
生成包可上传到FTP归档或直接部署到测试环境（具体可参考《高效研发之——工具篇(4)：Jenkins》），此处只演示上传到FTP归档。
生成包管理
执行构建任务
根据《高效研发之——工具篇(4)：Jenkins》中的建议，测试版本和发布版本的构建可手动执行，
参数化构建
选择Branch/Tag
选择工程
选择生成包类型
Jenkins是一款非常优秀的开源持续集成工具，通过界面基本配置，已经能满足比较规范场景下的持续集成和发布。对更复杂的场景，还可以通过Groovy, shell, Ruby, Python等脚本进行定制。
网友评论