模板插件（CloudBees提供的Jenkins Enterprise的一部分）为Jenkins带来了元编程。有三种方法可以考虑模板：屏蔽詹金斯来自最终用户的配置通用性：在许多情况下，Jenkins管理员需要用户输入几个特定于域的术语，但不将整个作业配置公开给他们。抓住跨环境配置的相同性：当组织拥有大量的工作只有几点不同。例如，从不同的Git存储库分支提取的作业开发者。写作一个没有实际编程插件的插件。我将在这个博客中讨论[1]和[2]。图1：模板类型模板插件有一个可重用组件的概念（只要把它们看作是面向对象编程范式中的类、属性和实例的等价物）。这些组件是构建块，可以用来构建其他组件，也可以（可选地）自己实例化。使用模板插件的一个巨大优势是，如果模板定义发生变化，那么它会反映在使用该模板的所有作业中；从而简化了对大量作业的管理。本博客重点介绍了两个组件：构建器和作业模板。图1显示了CloudBees可以用Jenkins Enterprise创建的不同类型的模板。生成器模板图1：模板类型通常开发人员最终使用shell脚本来满足诸如自定义部署、集成步骤等需求。这些脚本被添加到作业的构建步骤中，并作为作业的一部分运行。这些脚本跨作业使用，只在属性上有所不同。理想的解决方案是将这些脚本捕获到一个通用定义中，并将其应用于各个作业。这正是构建器允许你做的，它们也是最容易创建的模板！。图2显示了预创建的构建器如何在作业配置的addbuild步骤中唤醒某人。图3显示了这个特定构建器所需的配置信息。图2：添加构建步骤通过定义这个构建器，我捕捉到了上面[2]中提到的工作的相同之处。作业模板作业模板可以看作是建造者之上的一个抽象层次。这里我们将整个作业模板化，而不是作业的一部分。图4显示您可以创建一个类型为Wakeup job的新作业。唤醒作业是通过图1中所示的作业模板选项创建的。图3：配置生成步骤通常，在企业设置中，许多作业是以相同的方式生成的；例如，作业可能只因签出它们的分支而不同，或者测试可能因指向不同的数据库而不同。Jenkins管理员希望只向用户公开此配置，而不公开任何其他详细信息。这样，管理员就大大简化了最终用户的配置，并简化了管理维护，因为他知道用户不会错误地配置作业。图4：创建一个新的作业类型图5显示了唤醒作业的配置选项。最终用户看不到任何其他选项—作业可能是自由样式的作业，也可能是下面的Maven作业—最终用户并不关心。通过定义这个模板，我捕捉到了配置[2]的相同之处，并保护用户不受配置通用性[1]的影响。因此，模板简化了管理开销并捕获了组织内的最佳实践。我在wiki上写了一个简单的模板示例，它为用户构建了一个警报（或提醒）系统。唤醒报警系统的要求是它需要三个配置参数：唤醒谁？谁在叫醒他们？那么，在多长时间后他们应该被唤醒？解决方案该示例采用构建器模板，并允许您在现有作业（和新作业）中插入构建步骤。作业模板创建的作业仅显示所需的配置信息，其他所有内容都对创建作业的用户隐藏。因此，这个例子在两个抽象层次上都解决了这个问题。实际上，作业模板最终使用构建器模板作为构建块。模板让我想起了几年前我听到的一个非常尖锐的口号："我宁愿构建程序来构建程序，而不是构建程序。"——）CloudBees产品管理高级总监Harpreet Singhcloudbees.com网站