Introduction de plug-ins#

Elargissez IBM™ UrbanCode Velocity en configurant des intégrations de plug-in à des outils externes.

IBM UrbanCode Velocity utilise une architecture de microservices conteneurisée. Cela signifie que les plug-ins ne sont pas directement exécutés depuis IBM UrbanCode Velocity, mais depuis des instances conteneurisées gérées par une plateforme de conteneurisation. Les instances d'exécution sont créées à partir d'images sur le référentiel Docker Hub™. IBM UrbanCode Velocity extrait des images à partir de ce référentiel et crée des instances en fonction des besoins.

Pour les installations basées sur Kubernetes, comme OpenShift™, IBM UrbanCode Velocity utilise Kubernetes™ comme plateforme de conteneurisation. Un moteur de flux de travaux Argo gère le flux de travaux de plug-in. Un pod Kubernetes démarre lorsqu'une tâche de plug-in est demandée et adresse les résultats à IBM UrbanCode Velocity. Une fois cette opération terminée, le conteneur qui contient le plug-in prend fin.

Pour les installations basées sur Docker, IBM UrbanCode Velocity utilise Docker Compose en tant que plateforme de conteneurisation. Un conteneur Docker démarre lorsqu'une tâche de plug-in est demandée et adresse les résultats à IBM UrbanCode Velocity. Pour plus de détails, reportez-vous à Installation de plug-ins dans des produits UrbanCode.

Les plug-ins sont catégorisés à l'aide de méthode de collecte de données et de communication. En règle générale, les plug-ins sont conçus pour utiliser l'une des méthodes de communication suivantes.

• Webhook. Ces plug-ins utilisent des Webhooks pour communiquer avec un nœud final d'API IBM UrbanCode Velocity défini. Le Webhook sert à déclencher des événements de collecte de données. Les plug-ins AppScan™ et SonarCube sont des exemples.
• Poller. Ces plug-ins se basent sur un événement défini par le plug-in. Des requêtes sont effectuées afin de déterminer le moment d'envoyer et de mettre à jour des données à partir du service externe. Les plug-ins GitHub™ et Rally sont des exemples.
• Parser. Ces plug-ins intègrent des fonctions permettant d'analyser un type de fichier spécifique et de créer un document d'indicateurs que IBM UrbanCode Velocity peut afficher avec d'autres vues de portefeuille et de gestion de chaîne de valeur. Les plug-ins JUnit et OneTest sont des exemples.

Si un plug-in n'est pas disponible pour votre outil, vous pouvez charger des indicateurs personnalisés à l'aide de nœuds finaux de l'API IBM UrbanCode Velocity.

Pour utiliser un plug-in, vous configurez une intégration. Le terme "Intégration" fait référence à une instance configurée par un utilisateur. Vous pourriez utiliser le plug-in GitHub pour configurer une intégration avec le référentiel ServiceA, puis une autre avec votre référentiel ServiceB. Bien que les deux intégrations utilisent le plug-in GitHub, chacune d'elles propose un jeu de données unique à IBM UrbanCode Velocity. Vous gérez chaque intégration séparément.

Certaines intégrations sont appelées "intégrations natives" et ne proviennent techniquement pas d'un plug-in. Les intégrations natives sont utilisées avec des plans de déploiement en définissant des tâches d'un type spécifique. Vous pouvez utiliser des données UrbanCode Deploy avec vos déploiements et vos pipelines, par exemple, en définissant des tâches de type UrbanCode Deploy.

Il se peut que certains plug-ins aient un plug-in correspondant dans l'outil externe. Pour intégrer Jenkins, par exemple, vous installez le plug-in "UrbanCode Velocity" dans Jenkins™ à l'aide du gestionnaire de plug-ins Jenkins. Ensuite, vous configurez une intégration Jenkins correspondante dans IBM UrbanCode Velocity. Les deux intégrations agissent en tandem.

Sujet parent : Extension des fonctions du produit