01 · Processus et communication : flux de travail, traçabilité, métriques et collaboration

Version : 1.1 · Date : 2026-10-22 · Domaine 1 de l'examen : Design and implement processes and communications (10 à 15 %)

En une phrase : avant les pipelines, AZ-400 vérifie que vous savez organiser le travail (GitHub Flow, Azure Boards, GitHub Issues et Projects), relier chaque changement à son besoin (AB#, section Development), mesurer le flux (lead time, cycle time, DORA) et faire circuler l'information (wikis, release notes, webhooks, Microsoft Teams).

Ce que l'examen demande#

Texte officiel du guide d'étude AZ-400 (compétences au 27 juillet 2026) :

1. Azure DevOps et GitHub : qui fait quoi#

L'examen mélange en permanence les deux plateformes. Il faut savoir où vit chaque fonction et comment les relier.

Les deux se combinent souvent : planifier dans Azure Boards, coder et automatiser dans GitHub. Les ponts officiels :

• l'Azure Boards app pour GitHub : liens AB#, transitions d'état, section Development (§ 4.5) ;
• Azure Pipelines sait construire un repository GitHub (service connection GitHub, GitHub App Azure Pipelines) et lier les work items aux builds ;
• les apps Microsoft Teams d'Azure Boards, Pipelines et Repos (§ 4.6).

Bon à savoir : depuis 2025, l'accès Basic à Azure DevOps est inclus pour les utilisateurs GitHub Enterprise Cloud (avec Microsoft Entra, puis aussi en data residency) : détection automatique à la connexion, niveau d'accès GitHub Enterprise, aucun coût en plus. Test Plans n'est pas inclus (il faut Basic + Test Plans) ; GitHub Enterprise Server n'est pas détecté. Astuce : assigner Stakeholder à ces utilisateurs pour ne pas payer Basic avant leur première connexion.

2. Traçabilité et flux de travail#

2.1 Structurer le flux de travail#

GitHub Flow, explicitement cité par l'examen, est le flux le plus simple :

1. une issue décrit le besoin ;
2. on crée une branche courte depuis main ;
3. on pousse des commits fréquents ;
4. on ouvre une pull request : revue, status checks (CI), discussions ;
5. on merge dans main, protégée par des branch protection rules ou des rulesets ;
6. main est toujours déployable ; on déploie depuis main (ou, variante, depuis la branche de la PR avant merge).

Les autres stratégies (trunk-based, feature branch, release branch, GitFlow) sont comparées au chapitre 02. Retenez ici que GitHub Flow convient au déploiement continu avec une seule version en production.

Dans Azure Boards, la structure du flux se règle par :

2.2 Les cycles de feedback#

Un cycle de feedback efficace capte un signal, le route vers la bonne personne et finit en élément de backlog.

• GitHub Issues : point d'entrée du feedback utilisateur. Structurer avec des issue templates / issue forms (.github/ISSUE_TEMPLATE/), des labels, des assignees et des milestones ; Discussions pour les questions ouvertes.
• Notifications :
  • Azure DevOps : abonnements personnels, d'équipe, de projet (Project settings > Notifications), filtrés par événement (build échoué, PR assignée, work item modifié) ;
  • GitHub : watch d'un repository, participation, @mention, CODEOWNERS qui demande automatiquement la revue au propriétaire du code.
• Canaux d'équipe : Microsoft Teams ou Slack (§ 4.6), plutôt que des e-mails individuels.
• Production : alertes Azure Monitor et Application Insights, qui peuvent créer un work item (chapitre 08).
• Feedback des parties prenantes : l'extension de navigateur Test & Feedback (Edge, Chrome ; Firefox retiré le 30/11/2026) sert aux tests exploratoires et crée bugs ou tasks, y compris pour un utilisateur Stakeholder. Attention : sur Azure DevOps Services, l'action formelle Request feedback et la page Feedback requests ne sont plus disponibles (elles restent sur Azure DevOps Server 2022) ; on suit les retours par une requête sur les bugs et tasks créés.

Piège : plus de notifications ne veut pas dire plus de feedback. La bonne réponse d'examen cible le destinataire (CODEOWNERS, abonnement d'équipe, canal dédié) et l'action (création d'un work item).

2.3 Suivre le travail : GitHub Projects, Azure Boards et repositories#

GitHub Projects : vues table, board et roadmap, custom fields (itération, priorité, estimation), workflows intégrés (ajout automatique des issues d'un repo, passage à Done à la fermeture) et automatisation par GitHub Actions ou l'API GraphQL. Un projet peut regrouper des issues et PR de plusieurs repositories.

Azure Boards reste plus riche pour la gouvernance : process personnalisés, requêtes WIQL partagées, Delivery Plans, traçabilité vers builds et déploiements. Une architecture de référence Microsoft (Power Platform ALM) le justifie ainsi : Azure Boards currently provides stronger enterprise work item process modeling, shared query and WIQL based release scoping, and richer built-in development and deployment traceability.

Limites de l'intégration Boards ↔ GitHub :

• un repository GitHub se connecte à une seule organisation et un seul projet Azure DevOps (sinon liens AB# imprévisibles) ;
• 2 000 repositories par connexion (web et API) ;
• seuls GitHub et Azure Repos sont intégrables (pas d'autre hébergeur Git) ;
• on ne peut pas requêter les liens GitHub : utiliser External Link Count > 0.

2.4 La traçabilité du code, des bugs et de la qualité#

Depuis GitHub vers Azure Boards : la syntaxe AB#

AB#{ID} crée un lien quand il apparaît dans un message de commit, une description de pull request ou une description d'issue. Il ne crée pas de lien dans un commentaire ni dans le titre d'une PR.

Les transitions ne s'appliquent que lorsque la PR est mergée dans la branche par défaut. Plus généralement, {state} AB#{ID} (ex. Validate AB#1234) applique cet état s'il existe, sinon la catégorie du même nom ; un mot inconnu est ignoré. Une note de version de 2025 dit que Fixes mène à « Closed » : la page de référence (Resolved, sinon Completed) fait foi pour l'examen.

Depuis GitHub vers GitHub Issues : les mots-clés de fermeture (close, closes, fix, fixes, resolve, resolves…) suivis de #12 dans la description d'une PR ferment l'issue au merge dans la branche par défaut.

Les autres maillons :

• section Development du work item : branches, commits, PR, builds liés ; on peut créer une branche GitHub depuis le work item, et le merge commit d'une PR est lié automatiquement ;
• section Development de la PR GitHub : affiche les work items cités par AB# dans la description ;
• pipeline YAML : option Automatically link work items included in this run, et lien Integrated in build sur les work items, y compris pour un repo GitHub ;
• qualité : les résultats de tests des pipelines sont liés au run ; un test en échec peut donner un bug lié au work item ; Azure Test Plans relie requirements ↔ test cases ↔ test results (traçabilité des exigences).

sequenceDiagram
    participant Dev as Développeur
    participant GH as GitHub
    participant AB as Azure Boards
    participant AP as Azure Pipelines
    Dev->>GH: PR « Fixes AB#123 » (description)
    GH->>AB: lien PR ↔ work item 123 (Azure Boards app)
    AP->>GH: build de la PR, status check
    Dev->>GH: merge dans main
    GH->>AB: work item 123 → catégorie Resolved
    AP->>AB: lien Integrated in build sur le work item

3. Métriques et requêtes#

3.1 Le tableau de bord du flux : lead time, cycle time, time to recovery#

Le widget Lead Time / Cycle Time est un nuage de points (un point = un ou plusieurs work items terminés), avec la moyenne mobile et une bande d'écart type. La fenêtre de la moyenne mobile vaut 20 % du nombre de jours affichés, arrondi à l'impair inférieur (30 jours → 5 jours). Prérequis : accès Basic, Azure Boards activé, Analytics ; seuls les types de work items présents dans un backlog sont sélectionnables.

Les 4 métriques DORA (DevOps Research and Assessment), reprises par le Cloud Adoption Framework :

Lecture classique : lead time qui augmente avec un cycle time stable → le travail attend avant de commencer (backlog trop long, priorisation). Cycle time qui augmente → goulot pendant le travail (revues, tests, environnements).

3.2 Métriques et requêtes pour la planification#

• Velocity (travail livré par sprint), Sprint burndown, Burndown / Burnup (Analytics), Cumulative Flow.
• Delivery Plans : vue calendrier de plusieurs équipes et de leurs dépendances.
• Requêtes WIQL (Work Item Query Language), partageables, affichables par les widgets Query Tile et Query Results :

SELECT [System.Id], [System.Title], [System.State], [Microsoft.VSTS.Common.Priority]
FROM workitems
WHERE [System.TeamProject] = @project
  AND [System.WorkItemType] = 'Bug'
  AND [System.State] <> 'Closed'
  AND [System.CreatedDate] >= @Today - 30
ORDER BY [Microsoft.VSTS.Common.Priority]

# La même requête en Azure DevOps CLI
az boards query --wiql "SELECT [System.Id], [System.Title] FROM workitems WHERE [System.WorkItemType] = 'Bug' AND [System.State] <> 'Closed'"

• Analytics pour aller plus loin :

Exemple OData : lead time et cycle time des user stories terminées depuis le 1er juillet 2026 (propriétés LeadTimeDays et CycleTimeDays de l'entité WorkItems) :

https://analytics.dev.azure.com/{org}/{project}/_odata/v4.0-preview/WorkItems?
  $filter=WorkItemType eq 'User Story' and StateCategory eq 'Completed' and CompletedDate ge 2026-07-01Z
  &$select=WorkItemId,Title,LeadTimeDays,CycleTimeDays,CompletedDateSK

StateCategory eq 'Completed' est indispensable : Analytics ne calcule LeadTimeDays et CycleTimeDays que pour les work items terminés (requête tirée de l'exemple officiel Lead time and cycle time sample report).

3.3 Métriques pour le développement#

Bonnes métriques : petites PR revues vite. Mauvaises métriques : lignes de code, nombre de commits par personne (elles encouragent les mauvais comportements).

3.4 Métriques pour les tests#

• Test Analytics des pipelines : pass rate, test failures, tendance des durées, filtres par branche ou fichier de test.
• Flaky tests : Project settings > Pipelines > Test management active la flaky test management (Azure DevOps Services seulement) : détection système (rerun dans la tâche VSTest ou rerun failed jobs) ou custom (API), puis option pour exclure les tests flaky du résumé afin qu'ils ne fassent pas échouer le pipeline (détail au chapitre 06).
• Widget Test Results Trend (Advanced), rapports Power BI de l'entité TestResultsDaily.
• Azure Test Plans : progression des plans de test, couverture des exigences.
• Couverture de code : publiée par le pipeline (chapitre 03).

3.5 Métriques pour la sécurité#

• GitHub Advanced Security (GitHub ou Azure DevOps) : alertes ouvertes par sévérité, délai de correction, secrets détectés, dépendances vulnérables (Dependabot) ; security overview au niveau organisation.
• Microsoft Defender for Cloud, DevOps security : vue unifiée des résultats des repos GitHub, Azure DevOps et GitLab, et annotations de PR (voir SC-500 chapitre 10 et chapitre 07).
• Indicateur utile : nombre de vulnérabilités critiques en production et âge moyen des alertes.

3.6 Métriques pour la livraison#

• Deployment frequency et lead time for changes (DORA).
• Pipeline analytics : rapports Pipeline pass rate (taux de réussite, tâches qui échouent le plus) et Pipeline duration.
• Environments : historique des déploiements par environnement et par ressource, traçabilité commit → déploiement.

3.7 Métriques pour l'exploitation#

• MTTR, change fail rate, disponibilité (SLA / SLO), nombre d'incidents, MTBF.
• Sources : Azure Monitor, Application Insights, outil de gestion d'incidents. Le détail de l'instrumentation est au chapitre 08.
• Le Cloud Adoption Framework recommande de mesurer peu de choses, avec une base de départ, et de privilégier les résultats (outcomes) aux activités (outputs).

4. Collaboration et communication#

4.1 Les wikis et les diagrammes Mermaid#

Azure DevOps propose deux types de wiki, tous deux stockés dans Git :

# Publier le dossier /docs du repo MyCodeRepo (branche main) comme wiki
az devops wiki create --name "Docs produit" --type codewiki --repository MyCodeRepo --mapped-path /docs --version main

Mermaid dans un wiki Azure DevOps (et dans les PR, les work items) :

• deux syntaxes : le conteneur ::: mermaid … ::: et, depuis 2026, le bloc de code standard (trois backticks suivis de mermaid), comme sur GitHub ;
• types pris en charge : sequence, gantt, flowchart, class, state, user journey, pie, requirement, gitGraph, ER, timeline ;
• limites : le mot-clé flowchart n'est pas accepté, il faut écrire graph ; pas de flèche longue ---->, pas de liens vers ou depuis un subgraph, la plupart des balises HTML et Font Awesome non pris en charge.

::: mermaid
graph LR;
    A[Commit] --> B(Build) --> C{Tests OK ?}
    C -->|Oui| D[Déploiement]
    C -->|Non| E[Bug]
:::

Côté GitHub : le wiki du repo, les README, GitHub Pages, et Mermaid rendu nativement dans le Markdown.

4.2 Release notes et documentation d'API#

• GitHub Releases : une release s'appuie sur un tag ; GitHub peut générer automatiquement les release notes (liste des PR mergées, contributeurs, lien vers le changelog complet). Le fichier .github/release.yml les classe par labels :

# .github/release.yml : catégories des release notes générées
changelog:
  exclude:
    labels: [skip-changelog]
  categories:
    - title: Nouveautés
      labels: [feature]
    - title: Corrections
      labels: [bug]
    - title: Autres changements
      labels: ["*"]

# Créer une release avec des notes générées
gh release create v1.4.0 --generate-notes

• Azure DevOps : pas de release notes générées nativement ; on les produit dans le pipeline (§ 4.3) à partir de l'historique Git et des work items liés au run, puis on les publie dans le wiki, comme artefact ou en pièce jointe d'une release.
• Documentation d'API : la spécification OpenAPI (anciennement Swagger) est générée depuis le code, puis publiée par le pipeline (Swagger UI, portail d'API, Azure API Management). Microsoft recommande de n'exposer l'UI interactive (Swagger UI, ReDoc) qu'en développement.

4.3 Générer la documentation depuis l'historique Git#

Principe : des messages de commit lisibles et structurés (par exemple Conventional Commits : feat:, fix:, docs:) donnent des release notes triées automatiquement.

# Azure Pipelines : release notes depuis le dernier tag
steps:
  - checkout: self
    fetchDepth: 0          # historique complet (désactive le shallow fetch)
    fetchTags: true        # les tags ne sont pas synchronisés par défaut sur les nouveaux pipelines
  - script: |
      PREV=$(git describe --tags --abbrev=0)
      echo "## Changements depuis $PREV" > release-notes.md
      git log --pretty=format:"- %s (%h)" "$PREV"..HEAD >> release-notes.md
    displayName: Générer les release notes depuis l'historique Git
  - publish: release-notes.md
    artifact: release-notes

Piège : dans beaucoup d'organisations, un pipeline créé depuis septembre 2022 (sprint 209) fait un clone superficiel (Shallow fetch, profondeur 1) et ne synchronise pas les tags (Sync tags désactivé). Sans fetchDepth: 0 et fetchTags: true, git describe ne trouve pas le tag précédent et les release notes restent vides. Une valeur dans le YAML l'emporte sur le réglage de l'interface.

Autres sources de documentation automatique : git log entre deux tags, liste des work items liés au run (API Azure DevOps), génération de la doc d'API à la compilation, README de modules générés par outil (par exemple Azure Verified Modules l'impose).

4.4 Les webhooks et service hooks#

Azure DevOps service hooks (Project settings > Service hooks > Create subscription) : un événement (build terminé, code poussé, PR créée, work item modifié, déploiement terminé…) déclenche une action chez un consumer :

• Droits : Project Collection Administrators ou Project Administrators.
• HTTPS uniquement (HTTP enverrait en clair les en-têtes d'authentification) ; pas de cible localhost ni d'adresse spéciale ; derrière un VPN, autoriser les adresses IP d'Azure DevOps en entrée.
• Bouton Test avant de finir ; le contenu envoyé se règle (Resource details to send, Messages to send).

GitHub webhooks (au niveau repository, organisation ou GitHub App) : choix des événements (push, pull_request, issues…), URL de payload, secret : GitHub signe chaque livraison avec l'en-tête X-Hub-Signature-256 (HMAC SHA-256), que le récepteur doit vérifier. Les livraisons récentes et leur réponse sont consultables et rejouables.

4.5 Connecter Azure Boards à des repositories GitHub#

1. Dans Azure DevOps : Project settings > Boards > GitHub connections > Connect your GitHub account.
2. Choisir l'authentification :
   • GitHub App (Azure Boards app) : recommandée, l'app agit à la place d'une personne ; nécessaire pour les status checks de PR et l'intégration GitHub Copilot ;
   • Personal access token : scopes classic repo, read:user, user:email, admin:repo_hook ; fonctionnalités limitées ;
   • OAuth (historique).
3. Sélectionner les repositories (jusqu'à 2 000 par connexion), installer l'Azure Boards app côté GitHub si demandé.
4. Si la liste des repos reste vide : la third-party application access policy de l'organisation GitHub bloque l'app ; un owner doit l'approuver (Settings > OAuth app policy).
5. Utiliser AB# (§ 2.4), ajouter le badge de statut au README, visualiser les objets GitHub sur le board.

Automatisation : API REST GitHub Connections pour ajouter ou retirer des repos en masse.

4.6 Microsoft Teams#

Contraintes : l'organisation Azure DevOps doit être dans le même tenant Microsoft Entra que Teams (même adresse e-mail ne suffit pas) ; créer un abonnement Azure DevOps dans Teams demande d'être Project Administrator ; les Office 365 Connectors de Teams sont retirés, remplacés par les apps ci-dessus ou Workflows (Power Automate). Azure DevOps Server passe par un service hook Teams.

flowchart TD
    A["Qui doit être informé ?"] --> B{"Équipe entière ?"}
    B -- Oui --> C["Canal Teams : app Azure Boards / Pipelines / Repos"]
    B -- Non --> D{"Propriétaire du code ?"}
    D -- Oui --> E["CODEOWNERS : revue demandée automatiquement"]
    D -- Non --> F{"Système externe ?"}
    F -- Oui --> G["Service hook / webhook HTTPS"]
    F -- Non --> H["Abonnement de notification personnel"]

5. Labs conseillés#

Organisation Azure DevOps gratuite (5 utilisateurs Basic inclus) et compte GitHub Free suffisent. Aucun coût Azure sauf le lab 5.

1. Boards ↔ GitHub : connecter un projet Azure DevOps à un repo GitHub par l'Azure Boards app ; créer une user story, ouvrir une PR dont la description contient Fixes AB#{id}, merger. Attendu : lien dans la section Development et passage à Resolved / Completed. Refaire avec AB# dans le titre : aucun lien.
2. Dashboard de flux : sur un board Kanban avec quelques éléments déplacés, ajouter les widgets Lead Time, Cycle Time, Cumulative Flow et un Query Tile sur la requête WIQL du § 3.2. Attendu : nuage de points avec moyenne mobile.
3. Code wiki + Mermaid : publier un dossier docs/ comme code wiki, ajouter un .order et un diagramme graph LR, puis tester le mot-clé flowchart. Attendu : graph s'affiche, flowchart non.
4. Release notes automatiques : dans GitHub, ajouter .github/release.yml, étiqueter deux PR, créer une release avec gh release create v0.1.0 --generate-notes. Attendu : notes classées par catégorie. Puis le pipeline du § 4.3 avec et sans fetchDepth: 0.
5. Service hook : créer un service hook Web Hooks sur « Build completed » vers une Azure Function HTTP (plan Consumption, quelques centimes), tester, lire le JSON reçu ; abonner un canal Teams avec l'app Azure Pipelines. Nettoyage : supprimer le resource group de la Function et le service hook.

6. Pièges d'examen#

7. Scénarios corrigés#

1. L'équipe planifie dans Azure Boards et code dans GitHub. Elle veut que la story passe en Resolved quand la PR est mergée, sans action manuelle.

Connecter le repo par l'Azure Boards app, et écrire Fixes AB#{id} dans la description de la PR ; la transition se fait au merge dans la branche par défaut.

2. Un manager veut savoir combien de temps un client attend entre sa demande et la livraison.

Widget Lead Time (création → fermeture). Pour l'attente jusqu'à la production, compléter par le lead time for changes DORA, mesuré par les déploiements.

3. Le cycle time est stable mais le lead time double en trois mois. Que regarder ?

La file d'attente avant le début du travail : taille du backlog, priorisation, WIP en amont ; le Cumulative Flow Diagram le montre (bande New qui s'élargit).

4. La documentation technique doit être revue en PR, versionnée par release (v1, v2) et publiée dans le wiki.

Publish code as wiki depuis le dossier docs/ du repo, une branche par version (jusqu'à 10), .order pour le sommaire.

5. Les release notes doivent être produites à chaque release GitHub, classées en « Nouveautés » et « Corrections ».

Release notes générées par GitHub + .github/release.yml avec des catégories basées sur les labels des PR.

6. Une plateforme interne doit recevoir un événement à chaque build terminé dans Azure DevOps.

Service hook de type Web Hooks sur l'événement Build completed, endpoint HTTPS ; si l'endpoint est derrière un VPN, autoriser les IP entrantes d'Azure DevOps.

7. Les approbateurs de production veulent valider les déploiements sans quitter Teams.

Azure Pipelines app for Teams : abonnement aux approbations et approbation depuis le canal. Vérifier que l'organisation est dans le même tenant Entra.

8. Le RSSI demande un indicateur de sécurité suivi chaque mois pour tous les repos GitHub et Azure DevOps.

Defender for Cloud DevOps security (vue unifiée) ou security overview de GitHub Advanced Security : alertes critiques ouvertes et délai moyen de correction.

9. Un rapport Power BI doit montrer le taux de réussite des tests par branche sur 90 jours.

OData sur l'entité TestResultsDaily (les Analytics views ne couvrent pas les tests ni les pipelines).

10. Les diagrammes Mermaid copiés depuis GitHub ne s'affichent pas dans le wiki Azure DevOps.

Remplacer flowchart par graph et retirer les syntaxes non prises en charge (flèche longue, liens vers un subgraph, HTML).

8. Pour aller plus loin#

• Azure Boards et GitHub Copilot : depuis un work item, créer une PR générée par l'agent Copilot (y compris avec des custom agents) ; nécessite une connexion GitHub App.
• Azure DevOps MCP Server : interroger work items, wikis et Analytics en langage naturel depuis un agent IA (VS Code, Claude Code).
• SPACE et DevEx : compléter DORA par la satisfaction et le ressenti des développeurs ; éviter les métriques individuelles.
• Platform engineering : mesurer l'adoption de la plateforme interne (Microsoft Learn, Platform engineering).
• GitHub Projects en tant que code : API GraphQL et Actions pour synchroniser projets, labels et milestones.

9. Fiche à retenir#

• GitHub Flow : branche courte + PR + main protégée et toujours déployable.
• AB# : commit, description de PR ou d'issue ; pas le titre ni un commentaire ; fix/fixes/fixed → Resolved sinon Completed, au merge dans la branche par défaut ; chaque item à transitionner a son mot-clé.
• Boards ↔ GitHub : GitHub App recommandée (status checks, Copilot), 1 repo = 1 organisation, 2 000 repos par connexion, OAuth app policy à vérifier.
• Lead time = création → fermeture ; cycle time = début du travail → fermeture ; DORA : deployment frequency, lead time for changes, change fail rate, MTTR.
• Analytics views = work items pour Power BI ; OData pour pipelines et tests ; WIQL pour les requêtes et widgets.
• Provisioned wiki ({projet}.wiki, wikiMain) ou code wiki (dossier d'un repo, .order, 10 branches, versionné).
• Mermaid : ::: mermaid ou bloc de code mermaid standard ; graph et pas flowchart.
• Release notes : GitHub generated notes + .github/release.yml ; Azure Pipelines : script git log avec fetchDepth: 0 et fetchTags: true.
• Service hooks : Project Administrators, HTTPS, test ; webhooks GitHub signés (X-Hub-Signature-256).
• Teams : apps Boards / Pipelines / Repos, même tenant Entra, Office 365 Connectors retirés.

Références#

Lues le 21/10/2026 :

• Study guide for Exam AZ-400
• What is the Azure Boards-GitHub integration?
• Link GitHub commits, pull requests, branches, and issues to work items
• Connect Azure Boards to GitHub (cloud)
• Install the Azure Boards app for GitHub
• Integration with GitHub features timeline
• Work tracking, process, and project limits
• Configure lead time and cycle time widgets
• Cumulative flow guidance for lead time and cycle time
• Out Of Box widget catalog
• What is Analytics?
• Analytics query tools
• Create a Power BI report from a default Analytics view
• DevOps considerations (Cloud Adoption Framework)
• Provisioned wiki vs. published as code wiki
• Publish a Git repo to a wiki
• Wiki file and folder structure in Git
• Use Markdown in Azure DevOps (Mermaid)
• Sprint 274 update : standard Mermaid syntax
• Integrate with service hooks
• Webhooks
• Azure DevOps integration with Microsoft Teams
• Workplace messaging apps
• Design and implement branch strategies and workflows (module)
• ASP.NET Core web API documentation with Swagger / OpenAPI
• GitHub Docs : Automatically generated release notes
• GitHub Docs : Linking a pull request to an issue
• GitHub Docs : About Projects
• GitHub Docs : Validating webhook deliveries