一次编译、不同项目配置、多个发布环境，流水线怎么串起来？
目前在我们的容器环境里，存在多种不同业务模式的容器设计，虽然都是基于springcloud，但是组件千奇百怪，难以统一。 现在想统一容器业务架构及发版标准，计划做一下整改：Jenkins仍然作为打包发布工具，Nacos作服务中心和注册中心，GItlab作代码管理，harbor作镜像中心。Jenkins上配置不同环境参数对应容器平台内不同的namespace环境，编译时通过项目src下的profiles里建立不同目录来对应不同环境，Jenkins拉取代码编译时通过根pom指导变异并产生唯一jar，通过多份bootstrap控制运行过程中去指定不同的nacos配置名和提供不同环境nacos的连接信息。
这样整改后基本能做到一次编译、适配不同配置、发布到不同环境中，虽然能达成目标但需要指定和注入的参数特别多，不知道您这边是否还有其他的最佳实践或者我们这种思路还有什么优化空间？
1同行回答
这种情况很金融企业很类似，金融企业是因为区域的隔离，所以要求jenkins以不同参数的方式进行build。
一般情况下，持续交付流水线贯穿了业务需求、环境适配，研发、测试、安全、运维，最后上线，完成狭义上的“产品级”制品的交付，这个流程是没问题的。在多套环境下，举个例子，sit环境，pre环境，uat环境，prd环境。其中sit在办公区，pre在测试区内，uat和prd在生产区，可能每家机构都不太一样。那问题来了，全流程贯通，如何实现，是分开跑，还是集成在一起。
回答这个问题之前，需要考虑一件事，其实不仅仅是流水线，更重要的是组件库和制品库，制品库包括了war包，容器镜像之类的，也是受到网络隔离的影响。
笔者所在的机构是这样的，多个区域的网络限制虽然是物理隔离的，但物理隔离的区域有数据的交换空间，制品库和组件库通过这个交换空间进行数据同步和传输，举个例子，一个上线流程通过OA发起，OA在办公区内，流程数据和状态同步至DevOps平台的上线策略模块，执行上线计划的时候，会触发制品标签，发sit会去sit包，发prd会去取prd包。这种情况下只要保证交换区的网络安全和信息安全，便不会出现问题。