Aller au contenu principal

Azure Boards

Azure Boards est l’outil de suivi des éléments de travail de Microsoft, intégré à Azure DevOps Services. Les éléments de travail sont identifiés par un numéro séquentiel (#12345) au sein d’un projet, souvent précédé de AB# dans les messages de commit pour les distinguer des références de tickets à la GitHub.

Côté Forgejo : suivi de tickets externe

Paramètres du dépôt → Fonctionnalités → Tickets → Utiliser un système de suivi d’issues externe.

ChampValeur
External issue tracker URLhttps://dev.azure.com/<your-org>/<your-project>/_workitems/edit/{index}
External issue tracker URL formathttps://dev.azure.com/<your-org>/<your-project>/_workitems/edit/{index}
External issue tracker number formatRegexp
External issue tracker number format regexp`(?:AB

L’expression régulière reconnaît à la fois AB#12345 (la référence Azure Boards canonique) et l’ancienne forme #12345. Remplacez <your-org> et <your-project> par les identifiants de votre organisation et de votre projet Azure DevOps.

Format de message de commit recommandé

refactor: extract token-exchange path

AB#34521

Le préfixe AB# est une convention souple issue de la documentation de l’équipe Azure DevOps ; si votre équipe utilise plutôt #12345 seul, l’expression régulière ci-dessus reconnaît les deux formes, mais mélanger les deux styles dans un même dépôt déroute les outils en aval.

Côté outil de suivi : Service Hooks (facultatif)

Pour qu’Azure Boards affiche les commits et pull requests liés sur chaque élément de travail :

  1. Azure DevOps → Project Settings → Service hooks → + Add subscription.
  2. Service : Web Hooks (dernière option de la liste ; Azure ne propose pas de service hook « Forgejo » natif, mais Web Hooks accepte n’importe quelle URL).
  3. Déclencheur : laissez « Code pushed » / « Pull request created » selon ce que vous voulez faire apparaître.
  4. URL : dans fremforge, créez D’ABORD un webhook sortant (admin → Webhooks → Add Webhook) avec pour cible https://dev.azure.com/<your-org>/<your-project>/_apis/git/repositories/<your-repo-id>/links, le point de terminaison d’Azure qui attache les liens. Collez cette URL dans l’abonnement Service Hook.

Le chemin est asymétrique (Forgejo → Azure), car Azure DevOps n’interroge pas les dépôts externes Forgejo ; il attend que les pushes lui soient notifiés par votre CI ou votre hébergeur de code. Le webhook sortant de fremforge est la bonne primitive.

Conséquences en matière de sous-traitance

Le plan de contrôle d’Azure DevOps Services est Microsoft Azure (régions US-Central et EU-West selon la résidence des données). Lorsque vous reliez fremforge à Azure Boards :

  • Les métadonnées de commit et les références de dépôts partent vers Microsoft Azure.
  • Inscrivez Microsoft Corporation dans votre registre des sous-traitants comme traitant des données à caractère personnel (adresse e-mail de l’auteur du commit, message de commit).
  • Le DPA de fremforge exclut explicitement les sous-traitants Microsoft (conformément à la position de souveraineté de la page Trust) : pour ce maillon, l’avenant au DPA de votre organisation est un document autonome.

Pour les charges de travail attentives à la souveraineté, envisagez Plane (auto-hébergé, déployable dans l’UE, Apache 2.0) comme alternative à Azure Boards.

Ce que cette intégration ne fait pas

  • Pas de fermeture automatique à la fusion (Azure Boards prend en charge l’automatisation via les Work Item Automation rules ; configurez la règle sur la charge utile du Web Hook entrant).
  • L’intégration native d’Azure DevOps Repos (changement d’état à la fusion d’une pull request) ne s’applique PAS à Forgejo : ce lien est propre à Repos. L’intégration fremforge est à sens unique (commit / pull request → lien vers l’élément de travail), avec une automatisation de votre côté pour le sens inverse.
  • La synchronisation des sprints, itérations et area paths n’est pas couverte. Ce sont des notions internes à Azure qui ne se transposent pas proprement à un hébergeur Git.
Jira Data CenterLinear