Micro Focus Deployment Automation is delivered with a large number of "plugins"  (85 and counting). These plugins allow you to integrate and model processes for a large number of tools and technologies from Java and .NET web apps to databases, containers and the cloud. In order to provide a high level of flexibility, each plugin provides a number of discrete steps which can be joined together in the products sophisticated but easy to use process designer:

However, over time you will probably find yourself creating a great new process for a particular application and its technology only to find that you are copying it a number of times for similar applications. Rather than using such a difficult to maintain "copy-and-paste" approach it is much better to make use of Deployment Automation's component templates. As the name implies component templates can be defined that contain reusable processes. Consequently, rather than copying and pasting processes for similar applications you can simply instantiate a new component "based on" the template. If you change the underlying template then the instantiated component's processes will also be updated. That is if you want this behaviour - since everything is versioned in Deployment Automation you can also stay with a previous version of the template if desired.

To create a component template, you simply go to the "Management" view, select "Components" and then "Component Templates". Then click on the "Create" button and enter details of the new template as below:

I would recommend leaving "Source Config Type" as "None" unless you are pulling your artefacts from the same source each time. This way, each component can select its own source type - although the technical deployment processes might be similar one team might be pulling its artefacts directly from Git, another integrating into Jenkins and another Artifactory! After creating the template add properties and processes as you would normally do.

There are a few types of properties but the useful ones for reuse are environment and component version properties. Environment properties are typically used to override information that is different in each environment. Component version properties allow you to store data on each artefact version that is imported. These properties can contain data such as version control and issue tracking numbers that can be used when the version is deployed to update the relevant tools. For example update the issue tracking tool such as Jira or ALM Octane to say that the code for the issues have been deployed to an environment.

Over the years I have found myself creating a number of different templates including deploying .NET web apps to IIS, Java web apps to Apache Tomcat and for use in more ad-hoc deployment scenarios such as deploying database or business application changes (I will expand on "ad-hoc deployments" in another article at a later date). Rather than keeping these to myself I decided to upload them in to a GitHub repository which you can find at:

https://github.com/sda-community-plugins/component-templates

In this repository there is a description of each of the templates and in most cases an example of how to make use of them. As with most endeavours such as this, the templates are provided on an open source basis with no warranty or liability implied. Therefore I would recommend downloading and testing them in your own environment and make any changes where applicable. If you do find any problems or have any suggestions then please let me know.