Introducing plug-ins#

Extend UrbanCode™Velocity by configuring plug-in integrations to external tools.

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

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

For Docker-based installations, UrbanCodeVelocity uses Docker Compose as its containerization platform. A Docker container starts when a plug-in task is requested and sends the results to UrbanCodeVelocity. See installing plug-ins in UrbanCode products for details.

Plug-ins are categorized by data collection and communication methods. Generally, plug-ins are designed to use one of the following communication methods.

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

If a plug-in is not available for your tool, you can upload custom metrics using UrbanCodeVelocity API endpoints.

To use a plug-in, you configure an integration. "Integration" refers to a user-configured instance. You might use the GitHub plug-in to configure an integration with the ServiceA repository, and then configure another integration with your ServiceB repository. Although both integrations use the GitHub plug-in, each integration provides a unique set of data to UrbanCodeVelocity. You manage each integration separately.

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

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

Parent topic: Extending product functions