Aller au contenu principal

Intégrations

La plupart des équipes qui adoptent fremforge disposent déjà d’un outil de suivi des tickets (Jira, Azure Boards, Linear, Trello) et veulent que leurs modifications de code renvoient aux tickets qui les ont motivées. La plateforme Forgejo sur laquelle repose fremforge fournit une primitive de suivi de tickets externe qui gère le cas du lien cliquable à sens unique sans aucun développement : saisissez un motif d’URL dans les paramètres du dépôt, et chaque JIRA-123 présent dans un message de commit, un nom de branche ou un titre de pull request devient un lien cliquable menant directement à votre Jira (ou à Azure DevOps, Linear, ou une carte Trello).

Cette section explique la marche à suivre pour les six outils de suivi les plus demandés. Chaque page fait environ 50 lignes et couvre :

  1. Côté Forgejo : le motif d’URL, l’expression régulière et les champs des paramètres du dépôt.
  2. Côté outil de suivi : le webhook entrant facultatif (les notifications de pull requests et de commits apparaissent aussi dans votre outil de suivi).
  3. Conventions des messages de commit : la syntaxe que vos ingénieurs utilisent pour déclencher le lien (par ex. [JIRA-123], AB#456, LINEAR-789).
  4. Conséquences en matière de sous-traitance : ce que cela implique au regard de votre DPA fremforge lorsque des métadonnées de commit franchissent une frontière organisationnelle.

Choisissez votre outil de suivi

  • Jira Cloud : hébergé par Atlassian (*.atlassian.net).
  • Jira Data Center : Jira auto-hébergé sur votre infrastructure.
  • Azure Boards : l’outil de suivi de Microsoft, intégré à Azure DevOps.
  • Linear : l’outil de suivi cloud Linear.app.
  • Trello : l’outil de suivi à base de cartes d’Atlassian.
  • Plane : outil de suivi des tickets open source et auto-hébergé (Apache 2.0).

Gestion des incidents

  • ServiceNow : un incident ServiceNow pour chaque événement de sécurité (nouveau résultat critique, correspondance de malware, pull bloqué, violation de politique), via la Table API.

Ce qui n’est PAS couvert ici

  • Transitions d’état automatiques (« fermer JIRA-123 quand la pull request est fusionnée ») : fremforge ne fait pas (encore) évoluer automatiquement l’état des tickets dans votre outil de suivi externe. Le lien va dans un seul sens : commit / pull request / branche → outil de suivi. Le sens inverse (l’interface de l’outil de suivi affiche les commits liés) passe par le webhook entrant que fournit chaque outil ; configurez-le côté outil de suivi en suivant les instructions de chaque page.
  • Synchronisation des champs personnalisés : fremforge n’écrit pas dans les champs personnalisés, sprints, epics ou hiérarchies d’éléments de travail de l’outil de suivi. Ce sont des notions internes à chaque outil, trop variables pour être standardisées.

Si votre façon de travailler repose sur la fermeture automatique à la fusion, deux options s’offrent à vous :

  1. Automatisation côté outil de suivi : chacun des outils ci-dessus peut être configuré pour fermer un ticket à la réception d’un webhook portant une charge utile précise. Branchez le webhook sortant de fremforge (admin → Webhooks) sur le point de terminaison d’automatisation de votre outil de suivi et écrivez-y la règle de fermeture.
  2. Une Forgejo Action dans votre dépôt : ajoutez une étape qui envoie un POST à l’API REST de votre outil de suivi sur pull_request.closed avec le filtre merged: true. Un fichier de workflow de cinq lignes. Nous livrerons peut-être une version prête à l’emploi dans une prochaine version ; pour l’instant, c’est à construire de votre côté.

Empreinte en matière de sous-traitance

Relier des métadonnées de commit à un outil de suivi externe signifie que les messages de commit (et leurs auteurs) partent vers le cloud de cet outil. Pour les services de suivi hébergés, cela crée une nouvelle relation de sous-traitance ultérieure au titre de votre DPA fremforge. Chaque page indique le plan de contrôle concerné (États-Unis / UE / hybride) afin que votre AIPD puisse le mentionner correctement.

Les outils de suivi auto-hébergés (Jira DC, Plane) ne sont pas des sous-traitants ultérieurs : les métadonnées restent à l’intérieur de votre propre périmètre.