i

Description

Nef d’un atelier d’entretien ferroviaire, avec sa fosse et ses rails, ses étagères et ses rangements alignés.

Source

Samuel Zeller samuelzeller · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Azure DevOps Server (ex-TFS) en profondeur

Vous saurez décrire l'organisation Serveur → collections → projets → équipes, et ce qui est partagé ou isolé à chaque niveau.

En bref

• Vous saurez décrire l'organisation Serveur → collections → projets → équipes, et ce qui est partagé ou isolé à chaque niveau.
• Vous saurez choisir et personnaliser un process template (Agile, Scrum, CMMI, Basic, processus hérité) sans vous piéger.
• Vous maîtriserez work items, états, liens, area/iteration paths, backlogs, boards, capacité, requêtes WIQL, tableaux de bord.
• Vous saurez brancher Power BI sur les work items (Analytics/OData), utiliser l'API REST, et planifier une migration.
• Fil rouge : un datamart SQL Server alimenté par une application SFA, rapports Power BI multilingues, versionné en TFVC, livré en kits d'installation. Pour le versionnement, voir TFVC en profondeur.

Contexte de notation : équipe de 5 à 15 personnes, projet data/BI on-premise ; les notes /5 sont des appréciations (voir NOTATION).

Sur cette page

1. 🟢 Novice — Qu'est-ce que c'est, et quel nom porte-t-il aujourd'hui
   1. 🟢 Un cycle de vie moderne
2. 🟢 Novice — Organisation : collection, projet, équipe
   1. Combien de projets créer ?
3. 🟢 Novice — Process templates et types de work items
   1. 🟢 États, raisons et règles
4. 🟡 Pratique — Les liens entre work items
   1. 🟡 Le lien ticket ↔ changeset TFVC
5. 🟡 Pratique — Area paths et iteration paths
   1. Area paths : qui possède quoi
   2. Iteration paths : quand
   3. Conventions qui évitent les ennuis
6. 🟡 Pratique — Backlogs, boards, sprints, capacité
   1. Le Kanban board
   2. Le taskboard, la capacité, le burndown
   3. Les limites de l'outil en vélocité
7. 🟡 Pratique — Requêtes WIQL
8. 🟡 Pratique — Tableaux de bord et widgets
9. 🔴 Expert — Analytics, OData et Power BI sur work items
   1. Les trois façons de consommer
   2. Modèle de données conseillé pour un rapport projet
   3. Quand préférer l'accès SQL direct
10. 🔴 Expert — API REST, extensions et automatisation
    1. API REST
    2. Extensions
    3. Règles, crochets et notifications
11. 🔴 Expert — Processus hérité et pièges de personnalisation
    1. Pièges de personnalisation
12. 🔴 Expert — Test Plans et Pipelines, en deux mots utiles aux projets data
    1. Test Plans
    2. Pipelines
13. 🔴 Expert — Calendrier et plan de migration
    1. Plan type de montée de version on-premise (à adapter)
14. 🔴 Expert — Bonnes pratiques de structuration
15. Métriques — notation de l'outil
16. 🤖 Contribution de l'IA
17. Voir aussi

Niveau : 🟢→🔴

🟢 Novice — Qu'est-ce que c'est, et quel nom porte-t-il aujourd'hui#

Team Foundation Server (TFS) est l'ancien nom du serveur de collaboration de Microsoft (code, tickets, builds, tests). Il a été rebaptisé Visual Studio Team Services (VSTS) côté nuage, puis Azure DevOps Services, et Azure DevOps Server côté on-premise (à partir de la version 2019). Les noms existent en parallèle dans les têtes et les chemins : on dit encore « le TFS ».

Les fonctions sont regroupées en services :

🟢 Un cycle de vie moderne#

Selon les annonces Microsoft de fin 2025, Azure DevOps Server n'est plus millésimé : la dernière version (annoncée le 9 décembre 2025) est livrée sous la Modern Lifecycle Policy, sans numéro d'année ni date de fin de support fixe tant que l'on reste à jour des mises à jour et des prérequis système (état 2026-10, à revérifier sur la page de cycle de vie officielle avant toute décision de montée de version). Conséquence pratique : on ne choisit plus « 2022 vs 2025 », on s'engage à suivre les mises à jour, comme pour un service.

🟢 Novice — Organisation : collection, projet, équipe#

Serveur Azure DevOps Server
 └─ Collection de projets  (ex. DefaultCollection)        ← 1 base SQL par collection
     ├─ Projet « MonProduit »   (processus : Agile/Scrum/CMMI/Basic)
     │    ├─ Équipe « Datamart »  (backlog, sprints, capacité, board)
     │    ├─ Équipe « Rapports »
     │    └─ Équipe « Support »
     └─ Projet « Outils internes »

• Le serveur héberge une ou plusieurs collections. Une collection = une unité d'administration, de sauvegarde et de montée de version = une base SQL (Tfs_<Collection>). On peut détacher/attacher une collection (utile pour migrer, voir plus bas).
• Le projet (anciennement « projet d'équipe ») regroupe work items, dépôts, pipelines, wiki. Il applique un process template. Les area paths et iteration paths y forment l'arbre d'organisation et de planning.
• L'équipe est une vue : elle choisit des area paths (ce qu'elle possède) et des iteration paths (ses sprints), a un backlog, un board, une capacité, des widgets de tableau de bord. Un projet peut avoir plusieurs équipes ; un utilisateur peut en rejoindre plusieurs.

Combien de projets créer ?#

Règle d'expert : moins de projets, plus d'équipes. Un projet = une frontière dure (droits, processus, requêtes inter-projets limitées). Un projet par application multiplie les administrations et rend le reporting transverse pénible. Créer un projet séparé seulement pour : une exigence de confidentialité, un processus incompatible, ou un cycle de vie indépendant.

🟢 Novice — Process templates et types de work items#

Le process template décide des types de work items, de leurs états et champs.

Des types majeurs :

• Epic : grande initiative (plusieurs trimestres). Feature : capacité livrable (quelques sprints). Story / PBI / Requirement : valeur livrable en un sprint. Task : action technique (heures). Bug : défaut ; il peut être suivi comme une story ou comme une tâche selon la configuration du backlog de l'équipe (réglage « bugs » par équipe). Issue / Impediment : obstacle à lever. Test Case / Test Plan / Test Suite : types du service Test Plans.

🟢 États, raisons et règles#

Chaque type a ses états (champ System.State) et, pour chaque transition, des raisons (System.Reason). Des règles (champs obligatoires par état, valeurs automatiques, champs en lecture seule) accompagnent chaque transition. Exemple pour un Bug du processus Agile : passage à Resolved → champ « Resolved Reason » (Fixed, As Designed, Cannot Reproduce…) ; passage à Closed → vérification par le testeur.

🟡 Pratique — Les liens entre work items#

Les liens sont la vraie valeur de l'outil : ils transforment une liste en graphe traçable.

🟡 Le lien ticket ↔ changeset TFVC#

En TFVC, le check-in associe un ou plusieurs work items : dans Visual Studio (Team Explorer) en cochant l'élément dans « Related Work Items » ; en ligne de commande avec tf checkin /associate:12345,12346 (la syntaxe peut varier selon la version de tf.exe, à vérifier avec tf checkin /?). La politique d'archivage (check-in policy) « Work Items » peut rendre l'association obligatoire : à recommander pour tout dépôt qui produit des kits livrés.

# Archive en associant deux tâches et un commentaire, en environnement TFVC
tf checkin /comment:"Ajout du filtre secteur dans DIM_CLIENT" /associate:12345,12346 /noprompt
# Voir les work items associés à un changeset
tf changeset 45815

🟡 Pratique — Area paths et iteration paths#

Area paths : qui possède quoi#

Un arbre hiérarchique (MonProduit\Datamart\Dimensions, MonProduit\Rapports\Rapport Standard…). Il sert à : router des éléments vers l'équipe propriétaire, restreindre l'accès (droits par area path), filtrer des requêtes. Une équipe « possède » une ou plusieurs areas et, par option, leurs sous-areas.

Iteration paths : quand#

Arbre de planning (MonProduit\2026\Sprint 26-19). Chaque nœud porte une date de début et de fin. Une équipe sélectionne les itérations qu'elle utilise (sprints visibles dans son backlog). Les itérations sont partagées par le projet mais activées par équipe.

Conventions qui évitent les ennuis#

🟡 Pratique — Backlogs, boards, sprints, capacité#

Azure DevOps propose, par équipe, plusieurs niveaux de backlog configurables :

Les niveaux visibles sont réglés dans Paramètres d'équipe → Backlogs ; les bugs peuvent être traités comme des stories, comme des tâches ou ignorés dans le backlog.

Le Kanban board#

Colonnes = états, mais on peut découper une colonne en Doing / Done (« Split columns ») ; limites de WIP par colonne ; swimlanes (voies) pour les expédites ; règles de cartes (couleur selon un champ ou un tag) ; critères d'achèvement (checklist par colonne). Le board respecte l'ordre du backlog (Stack Rank).

Le taskboard, la capacité, le burndown#

Le sprint s'appuie sur trois écrans :

1. Planification : glisser-déposer des éléments du backlog dans le sprint ; l'estimation totale (points/heures) apparaît.
2. Capacité : par personne, jours hors poste, activité (Development/Testing/Design…) et capacité par jour (heures). Jours fériés de l'équipe renseignés une fois. Voyant de sur-engagement par personne et par activité.
3. Taskboard : colonnes To Do / In Progress / Done pour les tâches ; mise à jour du Remaining Work (reste à faire) ; burndown du sprint calculé en heures restantes ou en tâches (selon réglage).

Les limites de l'outil en vélocité#

Le widget Velocity agrège les points par sprint mais n'historise pas les changements de périmètre en cours de sprint avec la finesse d'un outil dédié ; pour un burnup fiable, utiliser Analytics (voir plus bas) ou la fonction « tendance du sprint ». Voir métriques et reporting.

🟡 Pratique — Requêtes WIQL#

Les requêtes sauvegardées sont des filtres partageables (liste plate, arbre, ou liens directs). Elles reposent sur le langage WIQL (Work Item Query Language), proche de SQL en lecture seule : SELECT … FROM WorkItems | WorkItemLinks WHERE … ORDER BY ….

-- Tâches actives de l'équipe dans le sprint courant
SELECT [System.Id], [System.Title], [System.AssignedTo], [Microsoft.VSTS.Scheduling.RemainingWork]
FROM WorkItems
WHERE [System.TeamProject] = @project
  AND [System.WorkItemType] = 'Task'
  AND [System.State] <> 'Done'
  AND [System.IterationPath] = @currentIteration
ORDER BY [System.AssignedTo], [System.Id]

-- Bugs anciens sans activité depuis 60 jours (santé du backlog)
SELECT [System.Id], [System.Title], [System.ChangedDate]
FROM WorkItems
WHERE [System.WorkItemType] = 'Bug'
  AND [System.State] IN ('New','Active')
  AND [System.ChangedDate] < @today - 60
ORDER BY [System.ChangedDate]

-- Stories sous une feature donnée, par liens hiérarchiques
SELECT [System.Id] FROM WorkItemLinks
WHERE [Source].[System.Id] = 1234
  AND [System.Links.LinkType] = 'System.LinkTypes.Hierarchy-Forward'
  AND [Target].[System.WorkItemType] <> ''
MODE (Recursive)

Macros utiles : @Me, @Project, @Today, @CurrentIteration, @TeamAreas, @StartOfWeek. Opérateurs : UNDER (pour les chemins), IN, CONTAINS, WAS EVER (historique d'un champ), EVER. WAS EVER est précieux pour les données de flux (« éléments qui ont été Bloqués »).

🟡 Pratique — Tableaux de bord et widgets#

Un tableau de bord d'équipe regroupe des widgets : Sprint Burndown, Velocity, Cumulative Flow, Cycle Time, Lead Time, Query Results, Chart for Work Items (camemberts, barres par état/assigné), Test Results, Build History, Markdown. Deux profondeurs :

• widgets de requête (un graphe sur une requête sauvegardée) : simples, instantanés, limités aux photos de l'état courant ;
• widgets Analytics (Velocity, Cycle Time, Lead Time, CFD, Burndown) : historiques, calculés sur la table des instantanés.

🔴 Expert — Analytics, OData et Power BI sur work items#

Analytics est le service de reporting de la plateforme : un modèle en lecture seule alimenté à partir des work items, avec historique (instantanés quotidiens et révisions). Intégré à Azure DevOps Services ; sur Azure DevOps Server il est installé et activé par collection (intégré à partir de la version 2020 ; sur 2019, extension à installer — à vérifier selon votre version). Il utilise l'index de recherche et un schéma dédié de la base de collection.

Les trois façons de consommer#

Exemple OData : nombre de bugs actifs par itération (agrégation côté serveur).

https://<serveur>/<collection>/<projet>/_odata/v4.0-preview/WorkItems?
  $apply=filter(WorkItemType eq 'Bug' and State ne 'Closed')/
         groupby((Iteration/IterationPath), aggregate($count as Total))

Exemple M (Power Query) minimal pour un flux OData, authentification Windows :

let
    Source = OData.Feed(
        "https://<serveur>/<collection>/<projet>/_odata/v4.0-preview/WorkItemSnapshot?" &
        "$filter=DateValue ge 2026-01-01Z and WorkItemType eq 'User Story'" &
        "&$select=WorkItemId,Title,State,StoryPoints,DateValue,AreaSK,IterationSK" &
        "&$expand=Iteration($select=IterationPath,StartDate,EndDate)",
        null,
        [Implementation = "2.0"]
    )
in
    Source

Modèle de données conseillé pour un rapport projet#

Tables : WorkItemSnapshot (grain = élément × jour : fait de flux), WorkItem (dimension courante), Iteration, Area, User, Date (calendrier). Relations en étoile ; mesures DAX de flux :

Éléments terminés =
CALCULATE ( DISTINCTCOUNT ( WorkItemSnapshot[WorkItemId] ),
            WorkItemSnapshot[State] = "Done" )

Cycle time moyen (jours) =
AVERAGEX ( VALUES ( WorkItem[WorkItemId] ), CALCULATE ( MAX ( WorkItem[CycleTimeDays] ) ) )

WIP =
CALCULATE ( DISTINCTCOUNT ( WorkItemSnapshot[WorkItemId] ),
            WorkItemSnapshot[State] IN { "Active", "Committed" } )

Les champs CycleTimeDays et LeadTimeDays sont fournis par Analytics. Pour les formules et l'interprétation, voir 10 — Métriques et reporting ; pour la conception du modèle Power BI, voir bonnes pratiques Power BI transverses.

Quand préférer l'accès SQL direct#

Il est tentant de lire la base de collection (Tfs_<Collection>, vues tbl_WorkItem*) en SQL. C'est non supporté par Microsoft (schéma interne, modifié à chaque version). N'utiliser que l'entrepôt Analytics et les vues documentées, et jamais d'écriture.

🔴 Expert — API REST, extensions et automatisation#

API REST#

Racine : https://<serveur>/<collection>/<projet>/_apis/…?api-version=<n>. Les versions d'API sont liées à la version du serveur ; choisir la plus haute supportée par le serveur cible. Quelques points d'entrée :

# Lecture d'un work item (auth intégrée Windows, serveur on-premise)
$uri = "https://tfs.exemple.local/tfs/DefaultCollection/MonProduit/_apis/wit/workitems/12345?`$expand=relations&api-version=7.0"
Invoke-RestMethod -Uri $uri -UseDefaultCredentials -Method Get

Quelques réflexes : ne jamais écrire directement en base ; utiliser l'API ou l'outil officiel ; limiter le débit (limites de taux sur Services ; sur Server la limite est celle de l'infrastructure) ; paginer avec $top et continuationToken.

Extensions#

Les extensions ajoutent widgets, onglets, actions de menu, tâches de pipeline, contributions de work item. Elles s'installent par collection (version Server) ou par organisation (Services). Écrire une extension demande : un manifeste vss-extension.json, du JavaScript/TypeScript ou une page web, un packaging tfx extension create. Pour un besoin simple, préférer l'API REST depuis un script planifié (alerte, synchronisation) à une extension.

Règles, crochets et notifications#

• Règles de processus (sans code) : champs obligatoires, valeurs conditionnelles.
• Service hooks : déclencher un webhook/Teams/Slack sur création ou changement d'état.
• Notifications par abonnement : à rationaliser, l'excès de courrier tue le signal.

🔴 Expert — Processus hérité et pièges de personnalisation#

Sur Azure DevOps Server récent on trouve deux modèles de personnalisation :

# Exporter le type « Bug » du projet (XML)
witadmin exportwitd /collection:https://tfs.exemple.local/tfs/DefaultCollection /p:MonProduit /n:Bug /f:Bug.xml
# Réimporter après modification
witadmin importwitd /collection:https://tfs.exemple.local/tfs/DefaultCollection /p:MonProduit /f:Bug.xml

Pièges de personnalisation#

🔴 Expert — Test Plans et Pipelines, en deux mots utiles aux projets data#

Test Plans#

Un plan contient des suites (statiques, par requête, par exigence) de cas de test (étapes, résultats attendus, paramètres). L'exécution produit des runs avec captures, journaux, bugs liés. Pour un projet BI, les cas de test paramétrés servent à la recette de chiffres : « pour le client X et le mois M, le total des ventes du rapport = valeur de référence ± tolérance ». Le résultat de chaque exécution est tracé (qui, quand, quelle version du kit). Voir recette et validation métier.

Pipelines#

Pipelines YAML (versionnés avec le code, recommandés) ou classiques (designer, héritage). Pour les projets data : étapes de compilation du projet de base (SSDT/sqlpackage), construction du kit d'installation, exécution de scripts de test, publication d'artefacts, déploiement vers un environnement de recette. Voir CI/CD et CI/CD pour la data.

🔴 Expert — Calendrier et plan de migration#

Trois chemins, selon la contrainte :

Plan type de montée de version on-premise (à adapter)#

🔴 Expert — Bonnes pratiques de structuration#

1. Une hiérarchie courte : Epic → Feature → Story → Task. Au-delà, personne ne s'y retrouve.
2. Définitions de prêt et de fini écrites dans le wiki du projet, liées au backlog.
3. Un champ, une décision : pas de champ sans consommateur.
4. Des équipes par flux de valeur, pas par couche technique (éviter « l'équipe base » et « l'équipe rapport » qui se passent des tickets).
5. Nommage uniforme des titres : verbe d'action + objet (« Calculer le linéaire par secteur »).
6. Lier systématiquement tâches ↔ changesets, bugs ↔ stories, stories ↔ features ; vérifier par requête (« stories sans parent », « bugs sans lien code »).
7. Hygiène de backlog : revue trimestrielle ; tout élément sans mouvement depuis 6 mois est soit fermé, soit raffiné (voir métriques — santé du backlog).
8. Documenter le modèle : une page wiki « Comment on utilise l'outil » (types, états, champs, liens, conventions), relue à l'arrivée de chaque nouveau.
9. Séparer incidents de données et bugs logiciels : types dédiés, SLA propres.
10. Mesurer le flux (lead time, cycle time) plutôt que de compter les heures saisies.

Métriques — notation de l'outil#

Voir la comparaison dans 12 — Comparatif.

🤖 Contribution de l'IA#

Prompt utile : « Voici une story et les règles du domaine. Propose 5 critères d'acceptation chiffrés et testables. Indique les hypothèses que tu fais ». Détails dans 11 — IA et outils.

Voir aussi#

• Panorama des outils · Jira et alternatives · Métriques et reporting · Comparatif
• TFVC en profondeur · Git en profondeur · GDS et données SQL/BI
• Scrum en pratique · Planification et estimation (matrice) · Glossaire

✻ Rédigé par Claude Sonnet 5.5