Introducing plugins

Extend HCL DevOps Velocity (Velocity) by configuring plugin integrations to external tools.

Velocity uses a containerized microservices architecture. This means that plugins are not run directly from Velocity but from containerized instances managed by a containerization platform. Runtime instances are created from images on the Docker Hub™ repository. Velocity retrieves images from this repository and creates instances as needed.

For Kubernetes-based installations such as OpenShift™, Velocity uses Kubernetes™ as its containerization platform. An Argo Workflow Engine manages plugin workflow. A Kubernetes pod starts when a plugin task is requested and sends the results to Velocity. When complete, the container containing the plugin ends.

Plugins are categorized by data collection and communication methods. Generally, plugins are designed to use one of the following communication methods.

  • Webhook. These plugins use webhooks to communicate with a defined Velocity API endpoint. The webhook is used to trigger data collection events. Examples include the AppScan™, and SonarQube plugins.
  • Poller. These plugins are based on an event defined by the plugin. Queries are performed to determine when to send and update data from the external service. Examples include the GitHub™, and Rally plugins.
  • Parser. These plugins integrate functions to parse a specific file type and create a metric document that Velocity can display with other value stream management and portfolio views. Examples include the JUnit, and OneTest plugins.

Available plugins are stored at HCL plugin database.

If you cannot find a plugin for your environment, you can create plugins by using the plugin software development kit (SDK).

If a metrics plugin is not available for your tool, you can upload custom metrics using Velocity API endpoints.

To use a plugin, you configure an integration. "Integration" refers to a user-configured instance. You might use the GitHub plugin to configure an integration with the Service A repository, and then configure another integration with your Service B repository. Although both integrations use the GitHub plugin, each integration provides a unique set of data to Velocity. You manage each integration separately.

Some integrations are termed "native integrations," and are not technically plugin derived. Native integrations are used with deployment plans by defining tasks of a specific type. You can use DevOps Deploy data with your deployments and pipelines, for example, by defining DevOps Deploy-type tasks.

Some plugins might have a corresponding plugin in the external tool. To integrate Jenkins, for example, you install the "Velocity" plugin into Jenkins™ using the Jenkins plugin manager. Then you configure a corresponding Jenkins integration in Velocity. The two integrations operate in tandem.