情况是这样的：对于基于Jenkins的多平台应用程序的每日构建，我有一个相当复杂的构建设置；对于Windows 7而言，它的构建过程非常简单。计时器触发了一个“根” Jenkins作业，它从适当的git-branch（基于提供的GIT_BRANCH参数）中选择了适当的/最新的git-revision，并触发了各种从属机器上的下游Jenkins作业来构建Mac，该git-revision中该应用的Windows和Linux可执行文件。一旦这些构建全部成功，就会触发进一步的构建作业来处理签名，打包并将构建工件上传到适当的位置。
这一切都很好，我对此感到非常满意-但是，因为它运作良好，所以我公司的多个团队都希望拥有自己的单独/私有实例。例如，主要开发人员的团队使用其实例获取基于git“ master”分支的每日构建，以帮助他们开发我们应用的下一代版本，而维护开发人员则使用其实例获取每日的构建。进行测试以测试他们在分支机构中进行的较小的维护修订，最后SQA团队也拥有自己的单独实例，为他们提供最新的候选发布者（来自另一分支机构）以评估即将发布。
要明确：这些组中的任何一个都不希望与其他任何组“共享”同一套Jenkins构建作业，因为共享会使他们难以相信“他们”的构建工件仍然存在是从“他们的” git-branch建立的。 （下载，安装和运行300MB的工件，只是为了发现SQA中的某人昨天更改了您的GIT_BRANCH设置以指向他们的git-branch，所以您浪费了半个小时来安装错误版本的应用，没意思）
因此，作为事实上的Jenkins经理，到目前为止，我的解决方案是设置一组Jenkins构建工作（大约十二个工作，所有这些工作都已参数化，因此可以设置为从任何git-branch构建） ，然后让他们按照自己的方式工作后，我将复制该组中的所有Jenkins构建作业，以便现在存在整个组的独立副本，该副本可以保存其自己的默认参数设置，存储它拥有自己的单独的构建工件目录，并且通常在生活中独立于原始集，同时执行几乎相同的构建过程。然后，我再次对第三实例进行此操作。
这行得通，除了必须维护三组相同的Jenkins作业真的很繁琐且容易出错-初始作业集复制每次大约需要一个小时，然后每当我需要进行更改时在Jenkins的工作流程中，我必须将每个更改应用于三个不同的地方。
我的问题是：在詹金斯中是否有建议的方法可以“实例化”一系列詹金斯工作，以便可以将相同的工作设置应用于多个詹金斯工作？还是我应该考虑采用其他方法来解决此维护/可伸缩性问题？