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.
The Templates plugin, available with CloudBees Jenkins Enterprise, 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:
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.
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 svn.mycompany.com/project/trunk, a dedicated Maven repository may be set at maven.mycompany.com/repositories/project, a QA Sonar instance may run at 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.
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.
The folder template can be used to define a set of jobs (that can themselves be defined by templates) to follow enterprise rules and best practices. 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.
Some examples of jobs might include:
- an SCM continuous integration job
- a continuous inspection nightly job to populate a Sonar QA server
- a continuous deployment job to push successful builds on a demo server
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.