Problem
You have common configuration scenarios that are replicated in multiple places. Making changes to any of the scenarios requires you to go to each configuration and change it manually. The manual process is error-prone and cannot be replicated easily. Thus, you cannot easily share best practices within various projects or jobs.

Solution
The Templates plugin captures the sameness of configuration in multiple places. Administrators define templates of jobs/build steps/publishers and replicate them while creating new jobs. Changes are made in one central location and are reflected in all dependent configurations.

The Templates plugin lets you define four types of templates:

• Builder
  Usually, developers have to create build steps as shell scripts to address enterprise requirements, such as those for: custom deployments, packaging, notification, and QA integration. These scripts are used for a large set of jobs and only differ by a few attributes. Maintaining such scripts and avoiding copy/paste mistakes can be a nightmare for large Jenkins installations. This template creates a new type of builder and avoids the need for users to copy scripts from one job to another.

• Job
  In many enterprise contexts, it is common for two projects to differ only by the project name. Similarly, source code management, repositories, or QA servers only differ by a sub-directory in a URL. For example, code may be hosted at http://svn.mycompany.com/project/trunk, a dedicated Maven repository may be set at http://maven.mycompany.com/repositories/project, a QA Sonar instance may run at http://project-sonar.mycompany.com/, and so forth. Job templates can be used to represent this model in an enterprise development environment by letting projects only define the minimal variable configuration to apply to the model. Thus, a job template offers a higher level of abstraction as it templates the definition of a whole job.

• Folder
  Administrators can configure a folder template that sets specific properties on a particular type of folder. Every time a new folder is created, it inherits those properties. Thus, the folder template is a way to define a standard structure for a folder so that it is applied with few parameters and in a simplified configuration. Such a template can be used to define a set of jobs (that can themselve be defined by templates) to follow enterprise rules and best practices, for example:

• a continous integration job on SCM head
• a continuous inspection nightly job to populate a Sonar QA server
• a continuous deployment job to push successful builds on a demo server
• …

Such a template defines the activities that a user will have to follow when using the template. You can then create a full wizard for a user to create the adequate folder and jobs structure for a new project.

• Auxiliary
  Auxiliary templates only define attributes. They are not expected to be used by end-users, but are useful to encapsulate a reusable set of attribute definitions that can used by other templates.