FlexDeploy provides dozens of out of the box plugins for building and deploying software using various technologies and middleware platforms. The FlexDeploy Plugin SDK allows customers or Flexagon partners to develop their own plugins. This guide provides the documentation for creating and managing these plugin implementations.

FlexDeploy plugins are implemented in Java or Docker image and are installed on the FlexDeploy server for use within workflows. These plugins are automatically distributed to the endpoints where they are defined to execute. A plugin consists of four components:

Implementation
- Java (See Plugin SDK API documentation ) or
- Docker image
Metadata describing its operations, properties, and other behavior
Setup scripts (optional) to initialize the environment prior to execution
Required FlexDeploy libraries for Java implementation (Java 8+ or Java 7 )

See detailed instructions below.

Development Approach

Decide on implementation type - Java or Docker, depending on your expertise.
Define plugin.xml and properties.xml files. This should help you describe operations that will be developed and project or environment/instance level properties used by each operation. You can also define plugin operation inputs as appropriate. At times, you can just use inputs without properties if it makes sense.
Developer plugin implementation.
Unit test plugin operations.
Package and verify on FlexDeploy server.

Plugin Implementation

Java Plugin

Plugin Lifecycle

Each plugin operation (e.g. build, deploy, start, stop) is implemented by extending AbstractPluginProvider.

Apache HTTP Server - AbstractPluginProvider implementation - build operation

public class Build
  extends AbstractPluginProvider
{
  private static final String CLZ_NAM = Build.class.getName();
  private static final FlexLogger LOG = FlexLogger.getLogger(CLZ_NAM);

  public Build()
  {
    super();
  }

  @Override
  public void validate()
    throws FlexCheckedException
  {
    //TODO
  }

  @Override
  public PluginResult execute()
    throws FlexCheckedException
  {
    //TODO
  }

  @Override
  public void cleanup()
  {
    //TODO
  }
}

Using the XML metadata which is packaged with the plugin, FlexDeploy will manage its lifecycle by invoking the methods implemented by the concrete class.

public abstract void validate() throws FlexCheckedException;
public abstract PluginResult execute() throws FlexCheckedException;
public void cleanup();

The validate method is responsible for validating that prerequisites are satisfied prior to performing the execution. As you will see later, the XML metadata identifies basic prerequisites (e.g. required fields) that will be enforced by the plugin framework. However, there may be more advanced validation which can be implemented within this method.

Apache HTTP Server - build operation

  @Override
  public void validate()
    throws FlexCheckedException
  {
    String methodName = "validate";
    LOG.logInfoEntering(methodName);
    //Let's validate that if a relative path is given, it exists on the file system.
    String relativePath = getRelativePathToFiles();
    if (relativePath != "")
    {
      File file = new File(getWorkflowExecutionContext().getTempDirectory() + relativePath);
      if (!file.exists())
      {
        throw new FlexCheckedException(ApacheHttpProperties.FDAH_00001_INVALID_PATH, "The given relative path, [" + relativePath + "] was not found in the FD_TEMP_DIR, or was not a relative path.");
      }
    }
    LOG.logInfoExiting(methodName);
  }

The execute method is responsible for performing the actual execution of the plugin operation.

Apache HTTP Server - build operation

  @Override
  public PluginResult execute()
    throws FlexCheckedException
  {
    String methodName = "execute";
    LOG.logInfoEntering(methodName);
    String source = getWorkflowExecutionContext().getTempDirectory() + getRelativePathToFiles();
    String destination = getWorkflowExecutionContext().getArtifactsDirectory() + File.separator + ApacheHttpProperties.ARTIFACTS_ZIP;

    LOG.logInfo("Zipping {0} into an artifact at (1}.", source, destination);
    int zipped = new FlexZipUtils(source, new File(destination)).zipFolder();
    getWorkflowExecutionContext().getOutputMap().put(ApacheHttpProperties.FDAH_FILE_COUNT, new PropertyValue(zipped, PropertyValue.PropertyTypeEnum.Integer, false));
    LOG.logInfo(methodName, "Done!");

    LOG.logInfoExiting(methodName);
    return PluginResult.createPluginResult(getWorkflowExecutionContext());
}

After performing the execution, the execute method is responsible for setting any outputs into the WorkflowExecutionContext and returning the result using the following code fragment.

The cleanup method is responsible for freeing any resources utilized by the plugin operation. Examples would be closing connections, deleting files, etc. Note that the cleanup method is provided as an empty implementation by the abstract class, and can be overridden by the concrete subclasses as needed.

Workflow Execution Context

The Workflow Execution Context provides information related to the current execution. This includes properties, inputs, the endpoint working directory (and its sub-directories), and other execution related information. The following table summarizes the working directory sub-directories and their purpose.

Directory	WorkflowExecutionContext Method	Physical Endpoint Location	Description

Directory	WorkflowExecutionContext Method	Physical Endpoint Location	Description
Working Directory	getWorkingDirectory()	<EndPoint Base Directory>/work/<Project Id>/<Workflow Request Id>	The temporary working area defined for the target endpoint.
Artifacts Directory	getArtifactsDirectory()	<Working Directory>/artifacts	Build operations which produce artifacts place those files here to have them automatically transferred back to the FlexDeploy server and version in the artifact repository. Deploy operations which consume artifacts will have those files delivered to this directory prior to execution on the endpoint.
Temp Directory	getTempDirectory()	<Working Directory>/temp	Temporary working area for a plugin operation execution.
Internal Directory	getInternalDirectroy()	<Working Directory>/internal	Internal working area for a plugin operation execution, which is not to be acessed or written to by workflow developers.
Reports Directory	getReportsDirectory()	<Working Directory>/reports	Files placed in the reports directory will be automatically be transferred back to the FlexDeploy server. They are displayed in the execution summary.
Transfer Directory	getTransferDirectory()	<Working Directory>/transfer	Files in the transer directory are automatically transferred back to the FlexDeploy server upon completion of execution, and likewise are transferred to the endpoint for the next workflow step. This provides a mechanism for sharing files between steps in a workflow.
Test Results Directory	getTestResultsDirectory()	<Working Directory>/test-results	Testing framework plugin executions place an XML document representing the test results into this directory, and they will be automatically be transferred back to the FlexDeploy server. See the xsd for formatting information. Results are displayed in the execution results pages, insights, reporting, and other locations.
Scan Results Directory	getScanResultsDirectory()	<Working Directory>/scan-results	Scanning framework plugin executions place an XML document representing the scan results into this directory, and they will be automatically be transferred back to the FlexDeploy server. See the xsd for formatting information. Results are displayed in the execution results pages, insights, reporting, and other locations.
Object Results Directory	getObjectResultsDirectory()	<Working Directory>/object-results	Build and Deployment plugin operations for partial deployment implementations place XML documents into this directory for identifying the objects included in the build, and their execution status at deployment time.

The AbstractPluginProvider base class has a number of methods for retrieving inputs/properties by type, based on scope, and returning a default if it is not defined.

See AbstractPluginProvider (FlexDeploy Plugin SDK javadoc) for a current list of methods that can be used to access the properties and values that you need.

Logging

Logging can be performed in plugin implementations by using the FlexDeployLogger class. The logger is statically initialized using the following two lines of code. Note that in this example Build would be replaced by the actual class name of the current class.

FlexDeployLogger initialization

Log messages can be added using any of the public methods available on FlexDeployLogger.

Logging methods

See FlexLogger (FlexDeploy Plugin SDK javadoc) for a current list of methods that can be used.

Docker image plugin

A plugin can be implemented as a Docker image (instead of Java implementation). In this case the "plugin.jar" file contains plugin.xml file only. The Docker image should be stored in a Docker repository accessible from an endpoint (Docker host or Kubernetes cluster) executing the plugin. The full name of the image including repository should be specified in ImageName element of plugin.xml file.

An example of plugin.xml file for FlexagonADFBuilderPlugin:

Oracle ADF plugin - plugin.xml

While executing a plugin operation on a Docker host, FlexDeploy runs the following command on the target endpoint:

Docker command structure

While executing a plugin operation on a Kubernetes cluster, FlexDeploy runs the following commands

Kubectl command structure

Note that images utilizing an entrypoint will not have their entrypoints called by the Kubernetes framework. This is to allow time for the working directory to be copied before execution starts.

FlexDeploy passes into the Docker container or K8 Pod values of the following environment variables (through env.list for docker) or (pod.json for K8):

FD_WORKING_DIR
FD_ARTIFACTS_DIR
FD_TEMP_DIR
FD_INTERNAL_DIR
FD_TEST_RESULTS_DIR
FD_OBJECT_RESULTS_DIR
FD_TRANSFER_DIR
FD_ENVIRONMENT_CODE
FD_ENVIRONMENT_NAME
FD_TARGET_GROUP_CODE
FD_TARGET_GROUP_NAME
FD_PROJECT_NAME
FD_PLUGIN_INSTALL_DIR
FD_ENDPOINT_NAME
FD_ENDPOINT_ADDRESS
FD_PLUGIN
FD_PLUGIN_OPERATION
FD_RESULT_FILE_NAME
All plugin operation inputs
All properties (by Name from metadata) for current project and target

The plugin execution working folder is mounted to the container as /fd_working_dir volume.

In order to return outputs the container must create a properties file /fd_working_dir/${FD_RESULT_FILE_NAME} containing output values. For example:

Example of result.dck file

Once the plugin operation finishes its execution, the corresponding Docker container or Kubernetes POD will be removed.

Plugin Metadata

Plugin XML

The plugin XML metadata (plugin.xml) defines information about the plugin, its operations, and its behavior. This XML file is bundled with the plugin Java class files and is used to integrate into the FlexDeploy platform.

plugin XML metadata schema (XSD)

Details of various elements is described in table below.

Element	Path	Description

Element	Path	Description
PluginDefinition	/	The root element for this plugin definition.
Name	/PluginDefinition	The name of the plugin, which appears on plugins page after upload.
PluginDisplayName	/PluginDefinition	The display name of the plugin, which appears on workflow page under workflow operations.
Description	/PluginDefinition	A description for this plugin, which is displayed on the plugins page after upload.
TechnologyGroup	/PluginDefinition	The name of the technology that is plugin is for, which is displayed on the plugins page after upload.
SubTechnologyGroup	/PluginDefinition	The name of the sub-technology that is plugin is for, which is displayed on the plugins page after upload.
Vendor	/PluginDefinition	The name of the vendor which authored the plugin.
Type	/PluginDefinition	Plugin type. Supported values are java and docker. Optional. Default is java.
ImageName	/PluginDefinition	Full name of Docker image
MaxConfurrentThreads	/PluginDefinition	The number of concurrent threads which are allowed to execute plugin operations on any single endpoint. Default is -1, which means unlimited.
Version	/PluginDefinition	The version of the plugin.
ResourceTypes	/PluginDefinition	A list of server/component types which are applicable for the underlying technology. This helps identify the endpoint to run a particular operation on. (e.g. for WebLogic - NodeManager, AdminServer, ManagedServer).
Resource	/PluginDefinition/ResourceTypes	A server/component types which is applicable for the underlying technology (e.g. NodeManager).
Operations	/PluginDefinition/	A list of operations supported by this plugin.
Operation	/PluginDefinition/Operations	An operation supported by this plugin.
Name	/PluginDefinition/Operations/Operation	The name of the plugin operation.
Description	/PluginDefinition/Operations/Operation	A description for the plugin operation.
Target	/PluginDefinition/Operations/Operation	For Java, the package qualified name of the Java class which implements PluginProvider or extends AbstractPluginProvider. For Docker, the command passed to image when the container is started.
PropertyKeys	/PluginDefinition/Operations/Operation	The list of properties used by this plugin operation. See Property Definitions section for details.
PropertyKey	/PluginDefinition/Operations/Operation/PropertyKeys	A reference to a property used by this plugin operation. See Property Definitions section for details.
Inputs	/PluginDefinition/Operations/Operation	A list of inputs used by this plugin operation.
AllowsUserDefined	/PluginDefinition/Operations/Operation/Inputs	Whether or not this plugin operation allows user defined inputs. User defined inputs are useful for low-level technology plugins (e.g. shell) where the user is essentially providing the implementation via source or scripting code.
Input	/PluginDefinition/Operations/Operation/Inputs	An input definition for this plugin operation.
Name	/PluginDefinition/Operations/Operation/Inputs/Input	The name of the input. Must be alpha-numeric, and be free of whitespace or special characters (except underscore). This name may be used in shell scripts or Groovy scripts and therefore must adhere to these variable naming standards.
DataType	/PluginDefinition/Operations/Operation/Inputs/Input	The data type of the input. Must be one of Boolean, Double, Integer, String.
Description	/PluginDefinition/Operations/Operation/Inputs/Input	The description of the plugin input, which is displayed on the plugin step editor of the workflow.
DisplayName	/PluginDefinition/Operations/Operation/Inputs/Input	The display name of the plugin input, which is displayed on the plugin step editor of the workflow.
DefaultValue	/PluginDefinition/Operations/Operation/Inputs/Input	The default value for the plugin input if no value is specified by the user. This value will also be displayed by default on the plugin step editor of the workflow.
IsDefaultValueExpression	/PluginDefinition/Operations/Operation/Inputs/Input	Identifies whether the default value for this input is an expression or a literal value, if specified.
SubDataType	/PluginDefinition/Operations/Operation/Inputs/Input	An optional sub-datatype for this input. Valid options are DIRECTORY, JDBCURL, and URL. Setting the SubDataType adds additional validation when user enters value.
IsRequired	/PluginDefinition/Operations/Operation/Inputs/Input	Indicates whether this input is required or not. Required inputs are enforced by the plugin step editor and at runtime.
IsEncrypted	/PluginDefinition/Operations/Operation/Inputs/Input	Indicates whether the input is encrypted or not. Encrypted values are masked on the editor, and their values are not displayed in log files.
MinValue	/PluginDefinition/Operations/Operation/Inputs/Input	Identifies the minimum required value for this input, and is enforced by the plugin step editor and at runtime. This value is only applicable for Integer and Double input types.
MaxValue	/PluginDefinition/Operations/Operation/Inputs/Input	Identifies the maximum required value for this input, and is enforced by the plugin step editor and at runtime. This value is only applicable for Integer and Double input types.
ListData	/PluginDefinition/Operations/Operation/Inputs/Input	Provides a list of values for this input which may be selected by the user on the plugin step editor. When ListData is provided the plugin step editor will render the value using a drop down component.
DisplayRows	/PluginDefinition/Operations/Operation/Inputs/Input	Defines the height of the input field on the plugin step editor.
DisplayColumns	/PluginDefinition/Operations/Operation/Inputs/Input	Defines the length of the input field on the plugin step editor.
LengthPrecision	/PluginDefinition/Operations/Operation/Inputs/Input	Defines the required input length. Only applies to String datatype.
ValidatorScript	/PluginDefinition/Operations/Operation/Inputs/Input	An optional Groovy script which is executed to determine whether this input's value is valid. The Value bind variable is set to the current value of this input, while every other input is available by it's name. The script must return true if validation passes, and false otherwise. When returning false, the variable ValidationMessage should be set to the message to display at runtime when validation fails.
IsMultiselect	/PluginDefinition/Operations/Operation/Inputs/Input	If the ListData attribute is provided, the IsMultiselect identifies whether the user can select more than one value. As such, the input component for this input on the plugin step editor behaves accordingly.
Outputs	/PluginDefinition/Operations/Operation	A list of outputs returned by this plugin operation's execution.
AllowsUserDefined	/PluginDefinition/Operations/Operation/Outputs	Whether or not this plugin operation allows user defined outputs. User defined outputs are useful for low-level technology plugins (e.g. shell) where the user is essentially providing the implementation via source or scripting code.
Output	/PluginDefinition/Operations/Operation/Outputs	The name of the output returned from this plugin operation.
EndPointSpecification	/PluginDefinition/Operations/Operation	Defines the strategy used for determining the endpoint or endpoints on which a plugin operation will execute on.
Selection	/PluginDefinition/Operations/Operation/EndPointSpecification	Defines which endpoints will be seleted as candidates to execute on.
All	/PluginDefinition/Operations/Operation/EndPointSpecification/Selection	Indicates that all endpoints associated to the target should be selected as execution candidates.
Resource	/PluginDefinition/Operations/Operation/EndPointSpecification/Selection	Indicates that only endpoints having the given resource name should be selected as execution candidates.
Delegated	/PluginDefinition/Operations/Operation/EndPointSpecification/Selection	Indicates that the endpoint selection is delegated to the workflow developer (within the plugin step editor). In this case, the plugin step editor will present options of All and Resource.
Execution	/PluginDefinition/Operations/Operation/EndPointSpecification	Of the selected endpoint candidates, determines which one(s) to execute on.
Any	/PluginDefinition/Operations/Operation/EndPointSpecification/Execution	Indicates to execute on one of the selected endpoints (at random).
All	/PluginDefinition/Operations/Operation/EndPointSpecification/Execution	Indicates to execute on all of the selected endpoints.
Delegated	/PluginDefinition/Operations/Operation/EndPointSpecification/Execution	Indicates that execution strategy is delegated to the workflow developer (within the plugin step editor). In this case, the plugin step editor will present options of Any and All.
ConsumesArtifacts	/PluginDefinition/Operations/Operation	Identifies whether this plugin operation consumes an artifact. Valid values are true, false, DELEGATED. In the case of DELEGATED, the plugin step editor will present a checkbox for the workflow developer to determine. When a plugin operation consumes artifacts, the associated artifacts from the artifact repository are copied to the artifact directory within the working directory on the endpoint prior to execution.
ProducesArtifacts	/PluginDefinition/Operations/Operation	Identifies whether this plugin operation produces an artifact. Valid values are true, false, DELEGATED. In the case of DELEGATED, the plugin step editor will present a checkbox for the workflow developer to determine. When a plugin operation produces artifacts, the associated artifacts from the artifact directory on the endpoint are copied back to the server and stored in the artifact repository.

Properties Definition

The PropertyKeys in the plugin.xml file reference properties that are defined externally to the file itself. This is done so that multiple plugin operations, and even multiple plugins, are allow to share properties. The properties are defined in another XML file, conforming to a different schema, and are bundled with the plugin. The schema, a description of its elements, and a sample XML file are provided below.

Plugin XML Properties Schema (XSD)

Details of various elements is described in table below.

Element	Path	XSD Line Number	Description

Element	Path	XSD Line Number	Description
PropertyList	/	4	The root element for this properties definition.
Name	/PropertyList	7	The name of the properties definition.
Property	/PropertyList	8	A plugin property definition.
Name	/PropertyList/Property	11	The name of the property. Must be alpha-numeric, and be free of whitespace or special characters (except underscore). This name may be used in shell scripts or Groovy scripts and therefore must adhere to these variable naming standards.
Description	/PropertyList/Property	12	A description for the property.
Scope	/PropertyList/Property	13	The scope of the property. Must be one of PROJECT, ENVINST (target renamed from Environment Instance).
DataType	/PropertyList/Property	14	The data type of the property. Must be one of Boolean, Double, Integer, String.
SubDataType	/PropertyList/Property	15	An optional sub-datatype for this property when the DataType is String. Valid options are DIRECTORY, JDBCURL, and URL. Setting the SubDataType adds additional validation when user enters value.
IsRequired	/PropertyList/Property	16	Indicates whether this property is required or not. Required properties are enforced at runtime.
IsEncrypted	/PropertyList/Property	17	Indicates whether the property is encrypted or not. Encrypted values are masked when entered by the user, and their values are not displayed in log files.
MinValue	/PropertyList/Property	18	Identifies the minimum required value for this property, and is enforced at runtime. This value is only applicable for Integer and Double input types.
MaxValue	/PropertyList/Property	19	Identifies the maximum required value for this property, and is enforced at runtime. This value is only applicable for Integer and Double input types.
ListData	/PropertyList/Property	20	Provides a list of values for this property which may be selected by the user on the various properties pages. When ListData is provided the editor will render the value using a drop down component.
DisplayRows	/PropertyList/Property	21	Defines the height of the property field on the editor.
DisplayColumns	/PropertyList/Property	22	Defines the length of the property field on the editor.
Validators	/PropertyList/Property	23	RESERVED FOR FUTURE USE
Validator	/PropertyList/Property/Validators	26	RESERVED FOR FUTURE USE
DisplayName	/PropertyList/Property	30	The display name of the plugin property, which is displayed on the editor where property values are entered.
DefaultValue	/PropertyList/Property	31	The default value for the plugin property if no value is specified by the user. This value will also be displayed by default on the editor where values are entered.
IsDefaultValueExpression	/PropertyList/Property	32	Identifies whether the default value for this property is an expression or a literal value, if specified.
IsAllowsVariant	/PropertyList/Property	33	RESERVED FOR FUTURE USE
LengthPrecision	/PropertyList/Property	34	Defines the required property length. Only applies to String datatype.
IsMultiselect	/PropertyList/Property	35	If the ListData attribute is provided, the IsMultiselect identifies whether the user can select more than one value. As such, the input component for this property on the various editors behave accordingly.

Plugin Setup Scripts

A plugin is executed on an endpoint by a wrapper java program, which is launched by a wrapper shell script. This wrapper shell script optionally sources in a setup script which is provided by the plugin. This setup script may perform initialization activities for the plugin. The following are examples of useful activities.

Append to the classpath by exporting the FLEXAGON_FD_PLUGIN_CLASSPATH variable.
Append additional JVM arguments to the Java invocation by exporting the FLEXAGON_FD_JAVA_ARGS variable.
Override the JAVA_HOME used to invoke Java by exporting JAVA_HOME variable (do not include bin folder).

The setup scripts have the following variables available to them:

JAVA_HOME (as defined by enpoint defintion's JDK Home)
FD_BASE_WORKING_DIR (as defined by endpoint definition's Base Working Directory)
FD_WORKING_DIR
FD_ARTIFACTS_DIR
FD_TEMP_DIR
FD_INTERNAL_DIR
FD_TEST_RESULTS_DIR
FD_OBJECT_RESULTS_DIR
FD_TRANSFER_DIR
FD_ENVIRONMENT_CODE
FD_ENVIRONMENT_NAME
FD_TARGET_GROUP_CODE
FD_TARGET_GROUP_NAME
FD_PROJECT_NAME
FD_PLUGIN_INSTALL_DIR
FD_ENDPOINT_NAME
FD_ENDPOINT_ADDRESS
FD_PLUGIN
FD_PLUGIN_OPERATION
All properties (by Name from metadata) for current project and target

The unix setup.sh setup script is used when executing on an endpoint using an SSH connection. And this is true on Windows platforms as well, since cygwin is used in that case. The setup.bat setup script is used only when executing on an endpoint using a localhost connection (and only in the event that the FlexDeploy server is running on Windows).

Plugin Unit Testing

To fully test your plugin you will ultimately need to upload it to a FlexDeploy Server. However, for unit testing purposes, it will be useful to test it a standalone testcase (e.g. using JUnit). To help provide the setup which is required to test your plugin, the MockWorkflowExecutionContext class is provided. This class manages manages some of the conext attributes that are otherwise handled by the FlexDeploy framwork. You will first need to satisfy the following prerequisites to test your plugin:

Add the FlexDeploy and 3rd party libaries to your classpath (i.e. adflibFlexFndCommonCore.jar, adflibFlexDeployCore.jar, commons-io-2.4.jar)
Add the following JVM arguments to your run configuration
- flexagon.fd.install.root=<FlexDeploy working directory> (can be any directory on your local computer)
- flexagon.fd.repository.root=<Directory to host FlexDeploy artifact repository> (can be any directory on yoour local computer)

The following setup must be performed using the JUnit @BeforeClass annotated methed, which will create the necessary FlexDeploy folders:

JUnit - @BeforeClass

Next is the implementation of a test case.

JUnit - @Test

A full example is provided with the source code for the Apache Http Server plugin.

Packaging a Plugin Version for Delivery

After you have finished developing and unit testing your plugin, you are ready to package it up into a JAR file in preparation for loading onto a FlexDeploy server.

To do that, cd to the folder that contains the files, and execute the following command: jar cvfM0 <PluginName>-<PluginVersion>.jar *

This will make "<PluginName>-<PluginVersion>.jar" which will contain the files and folders around it.

The JAR file has the following structure:

Plugin JAR Structure

Remember to update the plugin Version in the plugin.xml file when packaging.

Java Plugin Reference Example

A fully functional Apache HTTP Server plugin source code, is provided for reference throughout this documentation. This plugin provides four operations

build - packages web server content into a zip file artifact
deploy - deploys the zip file artifact produced during build to an Apache HTTP Server
start - starts an Apache HTTP Server
stop - stops an Apache HTTP Server

Apache HTTP Server Plugin XML Metadata

Sample plugin.xml

Apache HTTP Server Properties XML

Apache HTTP Server - AHS_PROPERTY_LISTING.xml (filename is irrelevant)

Installing Plugin on FlexDeploy

Once you have packaged your plugin into a JAR file, go to FlexDeploy and navigate to Administration → Plugins. Upload your JAR file, and activate the new version.

Best Practices

Use the following best practices when defining the Plugin XML Metadata/Properties for your plugin:

Prefix plugin Name with vendor/customer name (e.g. AcmeApacheHttpPlugin)
Set the Vendor to your vendor/customer name (e.g. Acme)
Give some thought to how users may want to sort/filter plugin operations when you set the TechnologyGroup (e.g. Web Servers) and SubTechnologyGroup (e.g. Apache Http Server) . Review Flexagon plugins for reference.
Prefix the Version of the plugin with the version of FlexDeploy it is compatible with (e.g. 4.0.12). The minor version has be updated everytime a new jar is built and available to be loaded onto a server (whether internally or externally). The version must be unique for every plugin.
Name plugin operations as <verb><noun> (e.g. stopServer, deployContent).
Name plugin inputs and plugin properties using <Vendor Prefix><Technology Prefiex>_<Some name>, and use all uppercase. (e.g. FDAH_START_TIMEOUT). In this example, FD is what Flexagon/FlexDeploy uses, and AH is the technology prefix for Apache Http Server. This will help ensure names are consistent and greatly reduce the risk of duplicate names across vendors/plugins.
Give careful consideration to the scope of your inputs/properties. If an attribute is likely to be fixed for every project and target, then it makes sense to be an input such that it is set once in the workflow. On the other hand, is the property likely to be environment specific? Is it likely to be project specific?

Limitations

The Plugin SDK has the following limitations:

Partial Deployment plugins are not supported.
SCM plugins can be created, however, they will not have integration with the Configuration tab of the FlexDeploy Project.