Azure DevOps – Nouvelle expérience de navigation

Overview :

regroupe l’accès aux informations générales du projet.

Summary permet de saisir une description générale du projet et d’afficher la liste des membres ainsi que quelques statistiques simples.

Dashboards liste les tableaux de bord disponibles pour le projet. Un tableau de bord existe par défaut à la création du projet mais est présenté vide de tout widget.

Wiki donne accès au wiki du projet. Il doit être crée explicitement par l’administrateur du projet.

Boards :

regroupe l’accès aux éléments de gestion fonctionnelle et organisationnelle du projet.

Work Items, les éléments de travail dont le type et les caractéristiques proviennent du modèle de gestion de processus choisi parmi Basic, Agile, Scrum ou CMMI. Ce choix a lieu lors de la création du projet.

Boards permet d’afficher le tableau Kanban selon le niveau du portefeuille des exigences Epics, Features ou Backlog Items.

Backlogs affiche le backlog de type liste, toujours selon le niveau retenu parmi Epics, Features ou Backlog Items.

Sprints permet l’accès aux informations de planification. Pour un Sprint donné, le Sprint Backlog sera disponible en vue liste (Backlog) ou en vue Kanban (Taskboard).

Queries ouvre la voie vers l’éditeur de requêtes offrant la possibilité d’associer un graphique aux résultats de la requête.

Repos :

représente tout simplement le contrôle de source. Ici, un repo pour un projet de type TFVC (Team Foundation Server Control), le système historique de Team Foundation Server.

Files est l’explorateur du contrôle de code-source.

Changesets est la liste complète et historisée des archivages contenant toutes les modifications remontées vers le serveur.

Shelvesets permet de stocker temporairement des modifications du code-source sans affecter le référentiel central du projet. Il s’agit des espaces de réservation dans la version française de Team Foundation Server.

La quasi-totalité des actions sur le code-source reste du côté du Team Explorer de l’éditeur (Visual Studio, Eclipse, Android Studio, …), fenêtre Explorateur de contrôle de code-source (ou Source control explorer en anglais)

Repos :

représente tout simplement le contrôle de source. Ici, un repo pour un projet de type Git, apparu avec Team Foundation Server 2013.

Files est l’explorateur de contrôle du code-source.

Commits est la liste complète et historisée des synchronisations avec le référentiel central.

Pushes est la liste complète et historisée des archivages contenant toutes les modifications. Cette liste est présentée par branche.

Branches permet la gestion des différentes branches du code-source du projet.

Tags positionne un marqueur dans l’historique du code-source. C’est l’équivalent du label en mode TFVC.

Pull Requests gère les demandes de revue de code avant une éventuelle fusion.

Pipelines :

regroupe les définitions de Build et de Release. C’est l’outil autorisant l’adoption d’une démarche DevOps complète comprenant l’Intégration Continue (CI : Continuous Integration) et le Déploiement Continu (CD : Continuous Deployment).

Builds regroupe toutes les définitions de Build créées pour le projet. Les Builds de type xaml utilisées dans les anciennes versions de Team Foundation Server sont maintenant obolètes. Les étapes de Build peuvent être affichées en wizard de type TFBuild comme le proposaient Team Foundation Server et Visual Studio Team Services. Ou bien les Builds peuvent être définies selon la nouvelle façon des scripts YAML.

Releases est destiné à la gestion des déploiements.

Library permet de regrouper des variables utilisées dans plusieurs pipelines de build ou de release. Egalement utilisé pour la gestion centrale des fichiers sécurisés.

Task Groups gère les tâches partagées entre plusieurs définitions de Build ou de Release.

Deployment Groups regroupe les différentes machines cible d’un même environnement. Typiquement, cela permet d’indiquer quelles sont les machines de l’environnement de Dev, celles de l’environnement de Test, celles de l’environnement de Recette, etc.

Test Plans :

la gestion des scenario de tests en trois niveaux possibles, plans de tests, suites de tests et cas de test. Exactement la même organisation des tests que dans Team Foundation Server et Visual Studio Team Services…

Test Plans permet de créer un plan de tests, niveau indispensable pour héberger les cas de test. Habituellement, un plan de test est mis en place pour chaque nouvelle itération, que ce soit un Sprint ou une Release comportant plusieurs Sprints.

Parameters définit l’ensemble des paramètres partagés qui vont ainsi pouvoir être utilisés dans plusieurs cas de test.

Configurations décrit l’ensemble des configurations différentes sur lesquelles les tests vont s’appliquer. Typiquement, les mêmes cas de test vont être exécutés sur une configuration iOS et une configuration Android avec, éventuellement, des résultats différents.

Runs affiche l’historique de l’exécution des cas de test. Répond aux questions qui a exécuté quoi et quand.

Load Test définit les tests de charge en mode Cloud.

Artifacts :

crée, héberge et partage des packages spécifique au sein du projet. En pratique, ces packages, par exemple NuGet pour le monde .NET, sont intégrés aux pipelines de Build et de Release pour faciliter l’Intégration Continue et le Déploiement Continu.