Plugin Creation Overview

A plugin consists of a ZIP file that contains a set of required and optional files in the root directory and supporting files located as needed. To make the plugin available for general use, this ZIP file must be loaded into Deployment Automation. The plugin files are described in the following section.

See also:

A short tutorial to create a "HelloWorld" plugin, available from the Community.

File	Description
plugin.xml	This file describes the steps provided by the new plugin. This file also contains informational elements such as description, name, and the location of the plugin in the Process Editor plugin list hierarchy. It is the main plugin file to create. (Required)
upgrade.xml	This file is used by Deployment Automation to upgrade plugins between versions. Plugins are versioned, like all Serena Deployment Automation entities, and this file is used to describe how to upgrade previous versions of the plugin to the latest. (Required)
info.xml	This file is used to detail the high-level plugin information such as who created the plugin and its current version. Although optional, Serena recommends the use of the info.xml file.
Other	Any supporting script files required by the plugin.

The plugin.xml file steps describe the functionality that can be used in the release process. Each step is defined by the use of the <step-type> element and contains the following supporting information:

Element	Description
<properties>	A container for <property> child elements, and can contain any number of <property> elements. Property values can be supplied at design-time or run-time. In addition to the properties defined locally in a step, a step can also access properties defined in other steps or even other plugins. This can be done by using the namespaces of the other steps or plugins to reference the property that is needed. For example, `<step-name>.<property-name>`
<command>	This element is used to detail the command that the plugin step is invoking. This command can be a shell script, an operating system command, or a program. It has a set of additional XML attributes that describe how the command is to be invoked.
<post-processing>	This element describes the logic that is to be invoked once the command has finished running and some kind of error-handling or post-command processing is desired.

Plugin steps are performed by an agent that has been configured to run on a target environment, so you must ensure that any step commands configured in the plugin are able to run on those agents. This may require additional software to be installed or licenses to be added as needed. If the appropriate software cannot be invoked correctly, an error message will be shown.

Once a plugin is created, load it into Deployment Automation to make it available to users.

To load a plugin:

Create a ZIP archive that contains the XML files (plugin.xml, upgrade.xml, and info.xml) along with any additional scripts required by the plugin.
Navigate to Administration > Automation.
In the selection box, select Plugins.
Click the Load Plugin button.
Click Choose File and select the ZIP file.
Click Load.