Vue d’ensemble de l’architecture pour Azure DevOps Server

Azure DevOps Server |Azure DevOps Server |Azure DevOps Server 2022 | Azure DevOps Server 2020

Pour mieux planifier et gérer votre déploiement, vous devez d’abord comprendre l’architecture sous-jacente d’Azure DevOps Server. Comprendre l’architecture peut vous aider à maintenir l’intégrité globale du déploiement et à garantir la disponibilité globale des serveurs et services dont vos équipes de développement ont besoin.

Vous pouvez déployer Azure DevOps Server de plusieurs façons : sur un seul serveur ; sur de nombreux serveurs ; ou dans un domaine ou un groupe de travail ou entre des domaines. Vous pouvez également choisir d’utiliser Azure DevOps Services, où tous les éléments serveur de votre déploiement sont hébergés pour vous par Microsoft. Comprendre l’architecture peut vous aider à déterminer la topologie qui est la plus susceptible de répondre à vos besoins métier. Quel que soit votre choix de topologie, si vous comprenez l’architecture sous-jacente à Azure DevOps Server, vous pouvez mieux gérer les exigences physiques et logiques. Cet article fournit une vue d’ensemble simple des différentes architectures, avec des liens vers des informations supplémentaires sur les exemples de déploiements. Il fournit également des informations techniques sur les services, les bases de données, les informations de configuration et les ports réseau et les protocoles des déploiements locaux.

Pour comprendre l’architecture d’Azure DevOps Server et la façon dont elle affecte votre déploiement, vous devez prendre en compte les éléments suivants :

• L’application logique, les données et les niveaux clients d’Azure DevOps, et que vous souhaitiez utiliser un ou plusieurs serveurs pour les niveaux d’application et de données, ou si vous souhaitez que les niveaux d’application et de données hébergés dans le cloud vous soient fournis à l’aide d’Azure DevOps Services
• Emplacement des serveurs physiques ou virtuels qui hébergent ces niveaux
• Team Foundation Build et le nombre et l’emplacement des ordinateurs de build qui s’exécutent dans votre environnement, y compris le nombre dont vous pourriez avoir besoin pour prendre en charge vos pratiques de développement, ou si vous utiliserez les services cloud Azure Pipelines pour créer et déployer vos applications logicielles
• Besoin potentiel pour le serveur proxy Azure DevOps

En outre, vous devez prendre en compte les interactions entre ces entités. Par exemple, si vous choisissez d’utiliser le service Azure DevOps Server hébergé, vous devez vous assurer que vos clients peuvent accéder au service sur le port 443. Si vous choisissez de déployer Azure DevOps Server localement, vous devez connaître les services Web, bases de données et modèles objet qu’utilise Azure DevOps Server. En outre, vous devez savoir quels ports réseau et protocoles Azure DevOps Server utilise par défaut et quels ports réseau vous pouvez personnaliser. Enfin, vous devez comprendre les autorisations que vous devez définir dans Azure DevOps Server et les composants et programmes dont dépend votre déploiement.

En plus de ses propres services, Azure DevOps Server dépend d’autres services pour fonctionner. Pour plus d’informations sur ces services, consultez les concepts et composants d’Azure DevOps Serverde l’entrepôt de données Azure DevOps Server. Pour plus d’informations sur les exigences et les dépendances pour l’installation, consultez le guide d’installation d’Azure DevOps Server.

Important

Vous ne devez pas modifier manuellement les bases de données Azure DevOps Server, sauf si vous êtes invité à le faire par le support Microsoft ou que vous suivez les procédures décrites pour sauvegarder manuellement les bases de données. Toutes les autres modifications peuvent invalider votre contrat de service.

Azure DevOps Services

Microsoft offre la possibilité d’utiliser Azure DevOps Services, qui peut héberger tous les aspects côté serveur d’Azure DevOps Server pour vous. Votre code source, vos éléments de travail, vos configurations de build et vos fonctionnalités d’équipe sont tous hébergés dans le cloud. D’un point de vue architectural, cela simplifie considérablement votre utilisation d’Azure DevOps Server, car les seuls aspects de l’architecture à prendre en compte sont les composants clients et leur accès Internet.

Lorsque vous utilisez Azure DevOps Services, vous utilisez un navigateur web pour vous connecter au service à l’aide de votre compte Microsoft. Vous pouvez créer des projets, ajouter des membres à votre équipe et travailler comme vous le feriez avec un serveur Azure DevOps installé localement, sans surcharge d’administration des serveurs. Azure DevOps Services héberge votre couche Application, la couche Données et les serveurs de build dans le cloud.

Pour en savoir plus sur les services cloud et les déploiements locaux, consultez Azure DevOps Services et Azure DevOps Server.

Modèle objet

Avec l’architecture hébergée ou déployée localement, vous pouvez étendre les fonctionnalités et fonctionnalités d’Azure DevOps en écrivant une application basée sur son modèle objet serveur ou client. Dans tous les types de déploiement, vous pouvez écrire des applications qui étendent les fonctionnalités du client. Toutefois, si vous souhaitez étendre les fonctionnalités du serveur, votre application doit s’exécuter sur le serveur de la couche Application. Pour étendre les fonctionnalités du client, vous devez exécuter l’application sur le même ordinateur que Team Explorer.

Services web et bases de données pour les déploiements locaux

Azure DevOps Server inclut un ensemble de services web et de bases de données que vous installez et configurez séparément sur le serveur ou les serveurs qui hébergent les niveaux logiques d’application, de données et de client pour Azure DevOps. Certaines fonctionnalités, telles que le tableau des tâches et les fonctionnalités basées sur l’équipe de backlog, sont entièrement basées sur le web et accessibles uniquement via un portail web, un service web côté client. D’autres, comme les fonctionnalités de contrôle de version, sont accessibles via un portail web ou via une application cliente. Les illustrations suivantes fournissent une vue générale des services web, des applications et des bases de données pour les déploiements locaux d’Azure DevOps Server.

Services au niveau de la collection

Les services au niveau du regroupement fournissent les fonctionnalités des opérations au niveau de la collection de projets. Vous pouvez créer des applications qui étendent Azure DevOps Server à l’aide de certains de ces services. Pour plus d’informations sur la création d’applications pour Azure DevOps Server, consultez Développer des extensions.

Remarque

Certains services apparaissent dans plusieurs niveaux. Par exemple, le service De Registre fonctionne au niveau de la collection et du serveur, et apparaît dans les deux listes.

Services d’infrastructure :

• Service de Registre
• Service d’inscription (pour la compatibilité avec les versions antérieures d’Azure DevOps Server)
• Service immobilier
• Service d’événements
• Service de sécurité
• Service de localisation
• Service Gestion des identités
• Service web contrôle de version
• Service de suivi Web des éléments de travail
• Service Team Foundation de Compilation Web
• Service web Gestion des laboratoires
• Service web d’administration VMM
• Service web du contrôleur d’agent de test

Services au niveau du serveur

Les services au niveau du serveur (également appelés services au niveau de l’application) fournissent les fonctionnalités des opérations pour Azure DevOps Server en tant qu’application logicielle. Vous pouvez créer des applications qui étendent Azure DevOps Server à l’aide de certains de ces services.

Services d’infrastructure :

• Service de Registre
• Service d’événements
• Service de collecte de projets
• Service immobilier
• Service de sécurité
• Service de localisation
• Service Gestion des identités
• Service d’administration
• Service de gestion des collections
• Service catalogue

Couche de Données

Le niveau données inclut les données, les procédures stockées et d’autres logiques associées. Lorsque vous utilisez Azure DevOps Services, le niveau de données est hébergé pour vous à l’aide de SQL Server Azure. Dans un déploiement local d’Azure DevOps Server, le niveau de données logiques se compose des magasins opérationnels suivants dans SQL Server. Ces magasins peuvent se trouver sur un serveur physique ou distribués sur de nombreux serveurs. Vous pouvez créer des applications qui étendent Azure DevOps Server à l’aide de certains de ces répertoires opérationnels.

• Base de données de configuration (TFS_Configuration)
• Entrepôt d’applications (TFS_Warehouse)
• Base de données Analysis Services (TFS_Analysis)
• Bases de données pour les collections de projets (TFS_CollectionName)

Le tableau suivant fournit la liste des bases de données qu’Azure DevOps Server utilise dans les déploiements locaux. Sauf indication contraire, vous pouvez déplacer toutes les bases de données de cette liste à partir du serveur d’origine et de l’instance où elles sont installées et les restaurer sur un autre serveur ou instance.

Nom de la base de données	Description	Serveur
TFS_Configuration	Cette base de données stocke le catalogue de ressources et les informations de configuration pour Azure DevOps Server. Cette base de données contient les entrepôts opérationnels de Azure DevOps Server.	Instance de SQL Server utilisée lors de l’installation et de la configuration d’Azure DevOps Server.
TFS_Warehouse	Cette base de données stocke les données des rapports.	Instance de SQL Server utilisée lors de l’installation et de la configuration d’Azure DevOps Server.
TFS_Analysis	Cette base de données multidimensionnelle stocke les données agrégées des collections de projets.	Instance de SQL Server utilisée lorsque SQL Server Analysis Services est installé et configuré.
Bases de données pour les collections de projets	Une base de données pour chaque collection de projets, contenant des données de tous les projets de cette collection.	Instance de SQL Server compatible avec Azure DevOps Server.

Niveau client

Le niveau client communique avec la couche Application via le modèle objet serveur et utilise les mêmes services Web répertoriés pour ce niveau. Cela est vrai si vous déployez Azure DevOps Server localement ou si vous utilisez Azure DevOps Services. Outre ce modèle, la couche client se compose de composants Visual Studio Industry Partners (VSIP), de l'intégration de Microsoft Office, d'interfaces de ligne de commande et d'une infrastructure pour les politiques d'enregistrement.

Paramétrage

Le service hébergé dépend des services clients, déployés localement et d’une connexion Internet aux niveaux d’application et de données hébergés dans le cloud. Un déploiement local d’Azure DevOps Server dépend de SQL Server, d’Internet Information Services (IIS) et du système d’exploitation Windows. En fonction de votre topologie choisie, Azure DevOps Server peut également dépendre de SQL Server Reporting Services ou de produits SharePoint. Par conséquent, les informations de configuration pour Azure DevOps Server peuvent être stockées dans l’un des emplacements suivants :

• Magasins de données IIS.
• Fichiers de configuration pour Azure DevOps Server.
• Sources de données pour Reporting Services (par exemple, données TFSREPORTS).
• Base de données de configuration pour Azure DevOps Server. Le registre Azure DevOps Server fait partie de la base de données de configuration.
• Registre Windows.

Pour obtenir des exemples de différentes topologies de déploiement local et où ces ressources sont stockées, consultez Exemples de topologie simple, Exemples de topologie modérée et Exemples de topologie complexe. Au fur et à mesure que vous gérez un déploiement local d’Azure DevOps Server, vous devez prendre en compte ces sources de configuration. Pour modifier la configuration de quelque façon que ce soit, vous devrez peut-être modifier les informations stockées dans plusieurs emplacements. Vous devrez peut-être également modifier les informations de configuration pour les niveaux données et clients. Azure DevOps Server inclut une console d’administration et plusieurs utilitaires de ligne de commande pour vous aider à apporter ces modifications. Pour plus d'informations, consultez la Référence rapide sur les tâches administratives.

Active Directory et synchronisation des identités de groupe

Dans les déploiements locaux où Azure DevOps s’exécute dans un domaine Active Directory, les informations de groupe et d’identité sont synchronisées quand l’un des événements suivants se produit :

• Le serveur de la couche Application démarre.
• Un groupe Active Directory est ajouté à un groupe Azure DevOps.

La période spécifiée dans le travail planifié s’écoule. La valeur par défaut est d’une heure et tous les groupes dans Azure DevOps Server sont mis à jour toutes les 24 heures.

Identity Management Services (IMS) se synchronise avec Active Directory et les identités modifiées se propagent du serveur aux clients. Par défaut, tous les groupes sont mis à jour dans les 24 heures, mais vous pouvez le personnaliser pour mieux répondre aux besoins de votre déploiement. Pour plus d'informations, consultez les considérations relatives aux confiances et aux forêts dans Azure DevOps Server. Pour les déploiements locaux qui n’utilisent pas Active Directory, consultez Gestion d’Azure DevOps Server dans un groupe de travail.

Groupes et autorisations

Dans un déploiement local, Azure DevOps Server a son propre ensemble de groupes et d’autorisations par défaut que vous pouvez définir au niveau du projet, de la collection ou du serveur. Vous pouvez créer des groupes personnalisés et personnaliser des autorisations au niveau du groupe et des niveaux individuels. Toutefois, les utilisateurs ou les groupes que vous ajoutez à Azure DevOps Server ne sont pas automatiquement ajoutés à deux composants sur lesquels les déploiements locaux d’Azure DevOps Server peuvent dépendre : produits SharePoint et Reporting Services. Si votre déploiement utilise ces programmes, vous devez y ajouter des utilisateurs et des groupes et accorder les autorisations appropriées pour que ces utilisateurs ou groupes fonctionnent correctement dans toutes les opérations dans Azure DevOps Server. Pour plus d’informations, consultez Gérer les utilisateurs ou les groupes dans Azure DevOps Server.

Pour les déploiements hébergés, l’accès est contrôlé par le biais d’une combinaison de comptes Microsoft et d’appartenance à l’équipe. Pour plus d’informations, consultez la vue d’ensemble d’Azure DevOps Services.

Ports et protocoles réseau

Par défaut, un déploiement local d’Azure DevOps Server est configuré pour utiliser des ports et protocoles réseau spécifiques. L’illustration suivante montre le trafic réseau pour Azure DevOps Server dans un déploiement simple.

De même, le service hébergé pour Azure DevOps Server est configuré pour utiliser des ports et protocoles réseau spécifiques. L’illustration suivante montre le trafic réseau dans un déploiement hébergé.

 

L’illustration suivante montre le trafic réseau dans un déploiement plus complexe qui inclut les composants de Visual Studio Lab Management. (Notez que la gestion des laboratoires a été déconseillée pour TFS 2017 et versions ultérieures.)

Les machines virtuelles utilisent le port 80 pour communiquer avec n’importe quel contrôleur de test sur le téléchargement d’un agent de gestion lab. Vérifiez que ce port est activé si vous rencontrez des problèmes de communication.

Paramètres réseau par défaut

Par défaut, la communication entre les ordinateurs dans un déploiement d’Azure DevOps utilise les protocoles et les ports indiqués dans le tableau suivant. Si un astérisque (*) suit le numéro de port, vous pouvez personnaliser ce port.

Niveau et service	Protocole	Port
Couche Application – Services web	HTTP/HTTPS	8080/443*
Niveau Application – Administration des produits SharePoint	HTTP	17012* si les produits SharePoint ont été installés avec Azure DevOps Server ; sinon, généré de manière aléatoire
Couche d'application – Produits SharePoint et Services de rapports	HTTP Service WMI (Windows Management Instrumentation) (requis pendant l’installation pour spécifier et vérifier les URL pour Reporting Services)	Port 80 dynamique*
Couche de Données	MS-SQL TCP	1433*
Niveau données (SQL Server Analysis Services)	MS-AS	par défaut (2382 ou 2383)* Le port par défaut varie en fonction de la version de SQL Server que vous avez installée et du type d’instance. Utilisez le Gestionnaire de configuration SQL Server pour déterminer les ports utilisés par votre déploiement.
Serveur proxy Azure DevOps - client au proxy	HTTP	8081*
Serveur proxy Azure DevOps - Proxy vers la couche Application	HTTP/HTTPS	8080/443*
Niveau client - Services de reporting	HTTP	80*
Niveau client - Services web	HTTP/HTTPS	8080/443*
Contrôleur de build vers la couche d'application HTTP/HTTPS	8080/443
Déployer l’agent vers la couche d'application	HTTP/HTTPS	8080/443
Serveur de gestion des versions	HTTP ou HTTPS	1000*
Client de gestion des versions	HTTP ou HTTPS	1000*
Agent de gestion des mises en production	HTTP ou HTTPS	1000*
Tester le contrôleur vers la couche Application	HTTP/HTTPS	8080/443*
Couche d'application destinée à tester le contrôleur	Communication à distance .NET	6901*
Couche d'application du système de noms de domaine (DNS)	Mise à jour dynamique DNS	53
Niveau d'application – Virtual Machine Manager	HTTP	8100
Contrôleur de test pour tester l’agent	Communication à distance .NET	6910*
Agent de test pour tester le contrôleur	Communication à distance .NET	6901*
Contrôleur de build pour générer l’agent	SOAP sur HTTP	9191
Agent de laboratoire à agent de laboratoire dans un environnement isolé	Sockets TCP	9050
Agent de build pour le contrôleur de build	SOAP sur HTTP	9191
Console d'administration de Virtual Machine Manager – Virtual Machine Manager	HTTP	8100
Virtual Machine Manager – hôtes Virtual Machine Manager	Windows Remote Management (WinRM) pour effectuer des actions Service de transfert intelligent en arrière-plan (BITS) pour transférer des données	80 pour effectuer des actions 443 pour transférer des données
Virtual Machine Manager – Serveur de bibliothèque Virtual Machine Manager	WinRM pour effectuer des actions BITS pour transférer des données	80 pour effectuer des actions 443 pour transférer des données
Couche d'application – Hôtes du gestionnaire de machines virtuelles	Communication DCOM/WMI (Distributed Component Object Model/Windows Management Interface) pour transférer des données	135 Affecté dynamiquement dans la plage 49152 à 65535
Niveau client – Hôtes Virtual Machine Manager	Connexion à la machine virtuelle basée sur l'hôte.	2179 pour effectuer des connexions basées sur l’hôte
Services hébergés	HTTPS	443

Paramètres réseau personnalisables

Comme le montre le tableau précédent, vous pouvez modifier la communication entre l’application, les données et les niveaux clients dans les déploiements locaux en modifiant Azure DevOps Server pour utiliser des ports personnalisés. Le tableau suivant décrit les exemples de modifications apportées aux ports HTTP vers HTTPS.

Remarque

Pour configurer Azure DevOps Server afin d’utiliser HTTPS et Secure Sockets Layer, vous devez non seulement activer les ports pour le trafic réseau HTTPS, mais également effectuer de nombreuses autres tâches. Pour plus d’informations, consultez Configurer HTTPS avec SSL (Secure Sockets Layer) pour Azure DevOps Server.

Service	Protocole	Port
Services web avec SSL	HTTPS	Configuré par l’administrateur
SharePoint Central Administration HTTPS	Configuré par l’administrateur
Produits SharePoint	HTTPS	443
Services de reporting	HTTPS	443
Services Web pour Clients	HTTPS	Configuré par l’administrateur
Gestion des versions	HTTPS	Configuré par l’administrateur

Articles connexes

• Concepts clés et termes