我工作的商店使用jenkins进行持续集成,并使用其推广的构建插件来部署构建工件。但是,随着配置数量的增加,我们无法管理此设置。所以我的问题是:
如何设置一个方便的CI系统,我可以从中以各种配置部署各种工件,而无需手动编写每种可能的组合?
更多细节:
假设我有构建配置(即分支)A
,B
和C
。有三个部署目标I
,J
和K
(适用于各种客户或消费者)。最后,每个部署的实例都有各种服务X
,Y
和Z
(例如网站,后台任务和数据服务)。各种服务通常一起推广;但有时候,特别是为了得到修补程序,它们不是。
目前,我们为每种组合提供促销活动。因此,要安装典型版本,我需要在配置J/X
上投放促销J/Y
,J/Z
和C
。不幸的是,服务的数量不断增加,并且在jenkins中获得所有这些配置而没有出现任何错误,并且进一步确保在部署到来时没有任何组件被遗忘或混淆变得棘手。当然,有三个以上的构建配置和三个以上的目标,所以一切都失控。
一些不太有用的选项:
参数化促销以禁用各种组件。 Jenkins允许参数化促销,但这些值会在您首次推广时得到修复。我可以通过仅提升J
并设置一些参数来消除一定程度的自由,但如果更高版本中断,我无法仅回滚损坏的组件,我需要回滚整个部署。
依赖的参数化构建。 Jenkins似乎不支持参数来选择要依赖的构建,如果您手动编写选项,那么“run”选择参数当然无效。
我真正想要的是什么:
手动接受构建以备部署之后,应将其标记为包含哪个组件的目标和参数的参数。
每个组件按目标记录安装历史记录,不(仅)按构建记录。
答案 0 :(得分:0)
可能有一些插件可以提供帮助,但您也可能正在接近寻找商业工具的点。我为一个构建/部署供应商(Urbancode)工作,所以无论如何都需要用一大块盐。
我们通常会看到人们对单个项目有不同的构建类型(或分支),并使用相同的基本配置和每个工作流参数化将这些组合作为具有多个“构建工作流”的单个“项目”。真正简单的重用过程。
不幸的是,服务的数量不断增加,并且在jenkins中获取所有这些配置而没有出现任何错误,并且进一步确保在部署到来时没有任何组件被遗忘或混淆变得棘手。当然,有三个以上的构建配置和三个以上的目标,所以一切都失控。
如果这里的挑战是你有多个网络服务和促销(特别是对于制作)涉及推动大量的东西,在特定版本,以协调的方式,你正在达到application release automation tool的标准用例,uDeploy。它与Jenkins方便地集成在一起。它还可以很好地跟踪哪些版本的部署目标,以及谁运行该流程。