07 Mai 2021

Dans un projet Azure DevOps, les ressources prennent des formes très variées : fichiers de code-source, tableaux, éléments de travail, requêtes, graphiques, builds, archivage, …

Dans cet article, nous allons nous intéresser aux liens entre une opération de code, typiquement un archivage, et un élément de travail.

Les captures d’écran en anglais sont issues de Azure DevOps Services. Si vous hésitez entre Azure DevOps Services et Azure DevOps Server, voici 5 éléments pour choisir.

Les liens entre les éléments de travail sont importants pour constituer la grappe d‘informations se rapportant à un même sujet. Par exemple, une Fonctionnalité (Feature) est décomposée, grâce au type de lien Parent-Enfant, en plusieurs Récits Utilisateur (User Stories ou Backlog Items), eux-mêmes découpés en plusieurs tâches (Tasks). Azure DevOps offre la possibilité de prolonger cette stratégie de liens avec d’autres ressources que les éléments de travail. Ainsi, nous pourrons relier les éléments de type « Tâche », qui décrivent le travail technique à réaliser, avec les archivages de code qui résultent des modifications apportées au code-source pour implémenter ces tâches.

Pourquoi relier un archivage de code avec un élément de travail ?

Relier un archivage de code avec un élément de travail présente plusieurs avantages :

• Etablir un pont entre la description fonctionnelle et l’implémentation technique.
• Pouvoir retrouver plus tard très facilement comment une fonctionnalité a été implémentée en partant de l’élément de travail fonctionnel.
• Pouvoir retrouver plus tard très facilement à quoi correspond une modification du code-source en partant de l’archivage (« commit »).
• Construire complètement la grappe d‘information d’un sujet particulier, que ces informations soient d’ordre fonctionnel, comme la description du besoin, ou d’ordre technique, comme la liste des implémentations à effectuer.
• Faciliter la transition dans la chaîne d’implémentation entre les équipes fonctionnelles ou métier et les équipes techniques de développement et de test.

Si l’on ne devait retenir qu’une seule bonne raison pour relier un archivage de code avec un élément de travail ce serait la suivante…

Logiquement, dans un environnement professionnel, on ne fait pas du code (que) pour le plaisir ou parce qu’on n’a rien de mieux à faire. On produit du code parce qu’il existe une demande dûment exprimée, répertoriée et planifiée !

Dans un projet Azure DevOps, la demande sera exprimée et partagée par des éléments de travail de type « Bug », « Fonctionnalité, « User Story » et la production du code-source sera entérinée par des archivages vers le référentiel central de code.

Nous verrons d’ailleurs comment rendre obligatoire le lien vers un élément de travail lors d’une opération d’archivage de code.

Comment créer un lien lors de l’archivage de code ?

L’opération d’archivage du code dans un projet Azure DevOps est complètement dépendante du type de contrôle de code-source choisi lors de la création du projet.

Azure DevOps soutient deux façons de gérer le code-source :

• Team Foundation Server Control (TFVC), le système historique existant depuis la première version de Team Foundation Server (TFS) en 2005 et directement issu de Visual Sourcesafe.
• Git, devenu clairement la référence depuis quelques années.

Créer un lien dans un projet TFVC

Dans un projet Azure DevOps en mode TFVC, l’archivage de code est géré dans la rubrique « Modifications en attente » du « Team Explorer ».

Il existe en fait trois façons de créer un lien vers un élément de travail sur un projet en mode TFVC, toutes se situent dans la rubrique « Éléments de travail associés » :

• 1. Entrer directement l’ID de l’élément de travail. C’est le plus simple… à condition de connaître cet ID.
• 2. Utiliser les requêtes. Une requête, qui remonte les éléments de travail qui nous sont assignés, est disponible par défaut. Fort logiquement, on ne devrait archiver du code qu’en lien direct avec des éléments dont on est responsable. On trouvera donc l’ID de notre élément de travail dans le résultat de cette requête.
• 3. A partir de l’entrée « Backlog » ou « Tableau » de l’interface web du projet Azure DevOps, on peut également glisser-déposer l’élément de travail dans la zone « Éléments de travail associés ».

Créer un lien dans un projet Git

Dans un projet Azure DevOps en mode Git, l’archivage de code est géré dans la rubrique « Modifications » du « Team Explorer ».

Il existe ici trois façons de créer un lien vers un élément de travail sur un projet en mode TFVC, toutes se situant dans la rubrique « Éléments de travail associés » :

• 1. Entrer directement l’ID de l’élément de travail. C’est le plus simple… à condition de connaître cet ID.
• 2. Ajouter en commentaire l’ID de l’élément de travail sous la forme #id. Exemple dans l’image ci-dessus avec un élément de travail dont l’ID est 367.
• 3. A partir de l’entrée « Backlog » ou « Tableau » de l’interface web du projet Azure DevOps, on peut également glisser-déposer l’élément de travail dans la zone « Éléments de travail associés ».

Consulter un lien archivage de code – élément de travail

La création d’un lien entre archivage de code et élément de travail va permettre une navigation très simple entre deux ressources du projet : l’une d’ordre fonctionnel et l’autre d’ordre technique.

A partir de l’élément de travail, il sera très facile de connaitre les différentes opérations de code qui ont permis d’implémenter techniquement le besoin décrit dans l’élément de travail.

A partir de l’archivage de code, il sera très facile de remonter jusqu’au besoin initial et donc de connaitre la raison de ces modifications sur le code.

A partir de l’élément de travail

Tous les liens renvoyant vers d’autres ressources du projet vont se retrouver en deux endroits sur la fiche de l’élément de travail : dans la colonne à droite de l’onglet « Détails » et dans l’onglet « Liens ».

La présentation des liens d’un élément de travail se découpe en trois catégories :

• 1. Liens vers les ressources de déploiement
• 2. Liens vers les ressources de développement, c’’est-à-dire toutes les opérations sur le code
• 3. Liens vers les autres éléments de travail, de même type ou de type différent

Dans cet article, nous nous intéressons aux liens de la deuxième catégorie et avons, dans notre exemple, cinq liens concernant des opérations de code classés du plus récent au plus ancien :

• Deux liens vers deux exécutions successives d’une pipeline de build
• Un lien vers une requête de tirage (« Pull Request ») en Git
• Deux liens vers des archivages de code (« Commits ») en Git. Ce sont ces deux liens qui vont nous amener directement aux modifications effectuées dans le code-source pour répondre au besoin exprimé par l’élément de travail.

Nous trouvons ici une autre façon de consulter l’ensemble des liens d’un élément de travail.

Peu importe la manière de présenter tous ces liens, l’intérêt est surtout d’assurer une facilité de navigation entre différentes ressources du projet traitant d’un même sujet au départ.

A partir de l’archivage de code

En ouvrant un archivage de code, par exemple un « Commit » sous Git, on peut consulter les liens dans l’onglet « Details » comme ci-dessous.

L’intérêt ici est de consulter très facilement la demande fonctionnelle qui justifie les modifications apportées au code-source.

Comment rendre obligatoire un lien avec un élément de travail lors de l’archivage de code ?

Espérant vous avoir convaincu de l’importance d’établir systématiquement un lien vers un élément de travail lors d’une opération de code, nous allons voir maintenant comment rendre ce lien obligatoire.

C’est une bonne pratique que nous recommandons lors de nos formations Azure DevOps

Attention, le paramétrage de cette obligation de lien vers un élément de travail est différent pour un projet TFVC et un projet Git.

Lien obligatoire dans un projet TFVC

Dans le cas d’un projet TFVC, il faut ouvrir les paramètres du contrôle de code-source du projet à l’aide du « Team Explorer » :

Il faut bien ouvrir les paramètres du contrôle de code-source au niveau du projet, et pas au niveau de la collection.

Si la stratégie « Éléments de travail » n’est pas présente, il suffit de l’ajouter…

Notez qu’il est recommandé de rendre également obligatoire la stratégie d’archivage sur les commentaires.

Lien obligatoire dans un projet Git

Dans le cas d’un projet Git, il faut passer par l’interface web pour accéder aux paramètres du projet. La stratégie d’archivage ne se situe pas au niveau du « Repository » mais au niveau de la stratégie de la branche.

L’image ci-dessous indique le parcours pour parvenir à l’option permettant de rendre obligatoire le lien vers un élément de travail pour une requête de tirage « Pull Request » :

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Le champ est obligatoire

Votre commentaire a bien été envoyé !

L'adresse électronique n'est pas valide

Envoyer