前言
现分享CI（Continuous Integration）自动化实践中的一些经验与心得及相关远景构想，欢迎探讨。由于一些原因，隐藏了一些具体技术细节及实现方式，敬请谅解。
项目現状
项目产品由几十个应用组成，代码由不同的语言编制，同时也是跨OS平台。代码由Git托管，用相应的工具和程序打包和执行单元测试，Artitactory代管程序包，SonarQube实现代码检测及结果呈现，Jenkins整合CI流程及触发CD过程。
各个应用的Jenkins jobs 采用FreeStytle类型，在原有的基本模版上修改而成，随着应用功能的增减也就变得的多式多样了。
面临的问题
- FreeStytle 类型不利于自动化的实施；
- 各应用Job的分散管理导致结果的不一致性。例如同一stage的名字都可能不一样的名称；
- 各应用的Jobs的特殊性，不利于集中管理。例如要增加一个通用过程的功能，必须告知各应用开发人员去更改相Job；
- 非集中式管理的各应用Job延缓了新功能的实施，降低了反应速度。例如要实CD的集成，必须对各应用Job分开修改测试；
- 新应用必须重新编制整个过程，上线速度太慢。
期望目标
- 实现Job的配置更新的可追踪性，便于管理；
- 保持CI过程的标准化和一致性，甚至包括名称的一致性；
- 实现同类或相似Job更改的自动化，提升响应速度；
- 降低Job与开发工作的相关性，减少对开发人员在Jenkins方便的技术要求；
- 建立CI过程的自动化流程，搭建CI自服务平台，提升CI的工作效率；
实施过程
1. 用Scripted Pipeline替换FreeStytle Job
- 将现有的Job从FreeStytle类型改为Scripted Pipeline，实现pipeline-as-code的目标，便于版本管理。
- 尽量地将各stage和step模块化，相互之间用子Job或Share Library实现解藕和传递数据。
2. 用标准化的pipeline模型实现统一管理
建立标准模型的工作流程
期望达到的目标：
- 当用户更改配置参数时，对应的应用pipeline立即发生相应变更，并自动更新产品包；
- 当模板变更时，基于该模板的各个应用pipelines可以按要求同步更新，并可根据要求决定是否重新生成产品包；
- 当应用代码更新时，CI过程即时触发更新产品包；
建立各类型Pipeline的标准化模型
期望达到的目标：
- 为每个类型的Pipeline建立必须并灵活的标准化模型；
- 为每个stage甚至step建立独立的pipeline，用参数调用的方式实现松耦合;
- 在step或stage之间通过copy artifact plugin 实现参数传递;
- 分析并解耦stage之间的逻辑关系，
为其独立运行奠定基础； - 尽可能将stage并行运行，加快pipeline的运行速度；
基于标准化模型，建立各应用Pipeline，实现CI过程的自动化
期望达到的目标：
- 用户只需按指定格式提供相应的参数变量，就可以自动建立相Pipeline;
- 任何参数变量的变更都会建立或修改相应的Pipeline，并能触发CI过程；
- 任何标准化模型的变更都可以自动或按要求触发相关应用的CI过程；
概念视图：
3. 整合Slave资源
期望达到的目标：
- 统一配置管slave，基于标准模型统一调度和分配slave；
- 随着CI过程的模块化和解藕过程的细化，逐步实现按过程（pipeline）的资源调度直至客器化调度；
远景展望
1. 集中展现CI完整流程
期望达到的目标：
- 展现整个流程的运行状况，并提供各个阶段的接入点；
- 提供各个阶段变更的整合信息，可追溯版本的关联性；
- 提供不同视角的数据分析报告；
2. 建立CI的自服务平台
期望达到的目标（类 GitOps）：
- 用户只需按要求提交相关信息，就可以自动建立或更改CI过程；
- CI过程可以跟据用户提交的变更信息自动触发，并生成新的产品包；
3. 无缝接入DevOps生命周期的全过程
期望达到的目标：
- 不断丰富CI过程；
- 向前与代码开发的pull request（commit）流程实现完全自动化整合；
- 向后与CD流程实现完全自动化整合；
Reference：
GitHub： https://github.com/xiaojias
来源：CSDN
作者：xiaojias333
链接：https://blog.csdn.net/tivoli_services/article/details/103751916