为什么会开始思考设计 jpl 和构建 CI/CD 平台？
项目越来越多，项目的构建方式各不相同， 在不同的项目团队CI 的能力水平不同，策略和模型方法也不同；整体上项目的CI 能处于较低水平（按照表-1评估处于1-2之间的能力阶段），需要系统性、自动化地提高整体的 CI 能力，提高研发效能。
表-1：CI 能力阶段
| 阶段 | CI 能力 |
|---|---|
| 1 初始阶段 | 用手工的方式或者部分自动化方式进行构建，构建环境不能保证稳定和一致性，各 种工具分散管理，对源码进行了版本控制 |
| 2 基础阶段 | 通过持续集成服务器进行定期的自动构建，按需手动构建，或者在代码提交之后触 发自动构建，基本可以保证构建是稳定的和可重复的，源码及构建所需的设定文件 和脚本都纳入了版本控制 |
| 3 可靠阶段 | 结合版本管理模型（分支模型）和开发方式，提供进一步的持续集成能力，不仅对 代码和构建所需脚本进行了版本管理，而且能够对进行标准化构建所需的一切都进 行版本管理，保证不会因为构建服务器的损坏而丧失稳定的构建能力 |
| 4 成熟阶段 | 具有每日数次部署或按需部署所需要的能力，使用基于主干的版本管理，构建过程 实时可视，结合版本管理、需求管理、缺陷管理、运维监控进行一定程度的集成管 理，能实现代码和需求的关联，缺陷和需求、故障和需求等局部关联，并可以进行 相关数据的展示和分析 |
| 5 优化阶段 | 依据持续集成的统计反馈信息进行不断改善和优化，形成需求、缺陷、运维、监控 统一的管理平台，以促进各个团队之间更好地进行协作和沟通 |
那 jpl 又是什么？
jpl 是一个内部公共的 Jenkins Pipeline Library ，基于 Jenkins 扩展共享库（Shared Library）的能力，用 groovy 代码定义和编排 CI/CD 流水线阶段和步骤，用于简化项目的 CI/CD 配置，提升项目的 CI/CD 能力：使项目保持频繁部署，快速生成可部署的软件，提高项目的能见度；快速发布，能够应对业务需求，并更快地实现软件价值；编码->测试->上线->交付的迭代周期缩短，同时获得迅速反馈。
jpl 基于 Jenkins 作为 CI/CD 的执行引擎，并结合当前公司业务特性和规范设计的多分支流水线，实现了包括：代码检出、前置检查（仓库规范、分支模型规范、Semver 规范）、编译和打包、Sonar 扫描、提交分析、自动归档制品、部署、触发自动化接口测试、自动合并代码、归档已发布代码、邮件通知等流水线步骤；借助 Jenkins BlueOcean 的功能使构建过程实时可视，并设计实现了一些常用的图形化操作：启停服务、从制品库发布、手动部署所有服务、刷新Jenkinsfile、跳过阶段、暂停进入调试。
jpl 实现了 Pipeline as Code，为 CI/CD 实践过程中的“最后一公里”保驾护航。
Ref
-
表-1 来自《企业级 DevOps 实战》
-
流水线即代码(Pipeline as Code)：通过编码而非配置持续集成/持续交付(CI/CD)运行工具的方式定义部署流水线
-
持续集成（continuous integration）
持续集成是一种软件开发实践，要求团队成员经常集成他们的工作。开发人员每次代码合并都会触发持续集成服务器进行自动构建，这个过程包括了编译、单元测试、集成测试、质量分析等步骤，通过自动化的过程进行验证，以尽快检测集成错误。这种方法会使得集成问题大幅减少，更快地实现有凝聚力的软件开发。
Martin Fowler