Serveur Azure DevOps

Au cœur d’Azure DevOps se trouve l’« élément de travail », qui peut représenter une tâche à accomplir, un risque à suivre, un cas de test, un bogue, etc. Les éléments de travail sont définis par des documents XML et sont hautement extensibles. Ils sont ensuite regroupés dans un modèle de processus qui contient ces informations, ainsi que d’autres éléments, afin de fournir un cadre de développement. Azure DevOps inclut des modèles de processus pour le framework Microsoft Solutions Framework for Agile, Scrum et CMMI.

Les éléments de travail peuvent être liés entre eux par différentes relations afin de créer une arborescence hiérarchique ou une relation linéaire. Ils peuvent également être liés à des artefacts externes tels que des pages web, des documents, du code source, des résultats de compilation, des résultats de tests et des versions spécifiques d'éléments dans le système de gestion de versions.

La flexibilité du système d'éléments de travail permet à Azure DevOps de remplir de nombreuses fonctions, de la gestion des exigences au suivi des bogues, des risques et des problèmes, en passant par l'enregistrement des résultats des revues. Ses fonctionnalités de liaison extensibles garantissent la traçabilité des exigences, du code source aux cas de test et aux résultats, et permettent de les documenter à des fins d'audit et de compréhension de l'historique des modifications.

Azure DevOps prend en charge deux types différents de contrôle de version : son moteur de contrôle de version d’origine appelé Team Foundation Version Control (TFVC) et, depuis la sortie de TFS 2013, la prise en charge de Git comme référentiel de contrôle de version principal.

L'infrastructure de reporting se compose d'un entrepôt de données , qui est une base de données relationnelle, et d'un cube de données SQL Server Analysis Services . Ces deux sources sont disponibles pour la génération de rapports via SQL Server Reporting Services (SSRS) lorsque cette option est installée. Comme il s'agit de structures de base de données et de cube standard, tout outil capable d'accéder à ces sources de données peut générer des rapports. Cela inclut des outils tels que Cognos, Tableau, Excel et d'autres outils de reporting. Chaque modèle de processus prêt à l'emploi inclut un ensemble de rapports pour les services de reporting, couvrant les informations de build, les résultats et la progression des tests, la gestion de projet, les rapports agiles (vue d'ensemble du backlog, graphique d'avancement des versions, graphique d'avancement des sprints et vélocité), ainsi que les données relatives aux bogues et aux problèmes. De nouveaux rapports peuvent être créés à l'aide de Report Builder pour SSRS et tous les rapports existants peuvent être modifiés.

TFS 2013 a introduit une nouvelle fonctionnalité appelée « reporting léger » qui permet de créer des rapports en temps réel basés sur les résultats de requêtes et qui ne dépendent pas de l'entrepôt de données ou du cube.

Team Build (avant TFS 2015) est une application serveur de génération incluse dans Team Foundation Server. Team Build se compose de deux éléments : MSBuild et Windows Workflow Foundation . MSBuild est un langage XML déclaratif similaire à Apache Ant .

Windows Workflow contrôle le déroulement global du processus de génération, et Azure DevOps inclut de nombreuses activités de workflow prédéfinies pour gérer les tâches courantes effectuées lors d'une génération. Le système de génération est extensible : les utilisateurs peuvent créer leurs propres activités de workflow, intégrer MSBuild au processus et exécuter des processus externes.

Le processus de compilation peut être configuré pour différents types de compilations, notamment les compilations planifiées, l'intégration continue , l'intégration contrôlée et les compilations progressives.

Le processus de génération dans Azure DevOps fait partie intégrante du mécanisme de traçabilité, car Team Build centralise la plupart des artefacts créés et stockés dans Azure DevOps. Si les développeurs associent le code source aux éléments de travail lors de l'archivage, Team Build peut générer des rapports sur les modifications apportées à chaque génération : modifications du code source, modifications des éléments de travail et résultats des tests. À mesure que les bogues et les éléments du backlog produit (PBI) sont résolus et intégrés aux générations, les éléments de travail qui suivent ces artefacts sont automatiquement mis à jour pour indiquer dans quelle génération ils ont été intégrés avec succès. Combiné aux outils de test, cela permet aux testeurs d'obtenir une vue intégrée du code modifié dans chaque génération, mais aussi des bogues, éléments du backlog produit et autres modifications d'une génération à l'autre.

À la mi-2013, Microsoft a fait l'acquisition d'InRelease, un produit d'InCycle Software. InRelease a été entièrement intégré à Team Foundation Server 2013. Cette fonctionnalité a complété les processus automatisés de compilation et de test en permettant une véritable solution de déploiement continu . Les outils ont été renommés « Gestion des versions » pour TFS 2013. Les fonctionnalités de Gestion des versions permettent aux équipes d'effectuer des déploiements contrôlés, pilotés par un flux de travail (fourni par Windows Workflow Foundation ), vers les environnements de développement, de test et de production, et fournissent des tableaux de bord pour suivre la progression d'une ou plusieurs versions.

Cette première version de Team Foundation Server a été publiée le 17 mars 2006.