Configuration requise pour Azure DevOps local
Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019
Avant d’installer ou de mettre à niveau un déploiement Azure DevOps, passez en revue les conditions requises fournies dans cet article.
En plus de ces exigences, consultez également les articles suivants :
- Compatibilité du client et de la build locale
- Exigences relatives au compte de service
- Présentation de l'architecture
- Ports réseau et protocoles par défaut
- Paramètres réseau personnalisables
- Compatibilité des versions et des artefacts Azure
Recommandations matérielles
Azure DevOps local peut être mis à l’échelle à partir d’une installation Express sur un ordinateur portable utilisé par une seule personne vers un déploiement hautement disponible utilisé par des milliers de personnes. Il peut prendre en charge des scénarios d’utilisation élevée qui ont plusieurs niveaux d’application derrière un équilibreur de charge et plusieurs instances SQL qui utilisent SQL Always On.
Les recommandations suivantes s’appliquent à la plupart des déploiements Azure DevOps. Vos besoins peuvent varier en fonction de la façon dont votre équipe utilise Azure DevOps. Par exemple, si vous avez des dépôts Git particulièrement volumineux ou des branches de contrôle de version Team Foundation (TVC), vous aurez peut-être besoin d’ordinateurs plus spécifiques que ceux répertoriés dans les sections suivantes. Toutes les machines décrites dans les sections suivantes peuvent être physiques ou virtuelles.
Déploiement de serveur unique
Un déploiement à serveur unique se compose d’un seul ordinateur avec un processeur double cœur, 4 Go de RAM et un disque dur rapide. Pour Elastic Recherche, vous devez utiliser deux processeurs double cœur et 8 Go de RAM. Cette configuration prend généralement en charge jusqu’à 250 utilisateurs du contrôle de code source principal (Team Foundation Version Control ou Git) et de la fonctionnalité de suivi des éléments de travail. L’utilisation intensive de la génération, du test ou de la mise en production automatisées entraînera probablement des problèmes de performances. Nous vous déconseillons d’utiliser les fonctionnalités de recherche ou de création de rapports pour cette configuration.
Lorsque vous effectuez un scale-up d’un serveur unique, le serveur peut gérer un plus grand nombre d’utilisateurs et une utilisation accrue de la génération, du test ou de la mise en production automatisées. Un serveur mis à l’échelle peut également utiliser des fonctionnalités de recherche ou de création de rapports. Par exemple, l’augmentation de la RAM à 8 Go doit permettre un déploiement à serveur unique de faire évoluer jusqu’à 500 utilisateurs.
Pour une évaluation ou une utilisation personnelle, vous pouvez utiliser une configuration de base avec aussi peu que 2 Go de RAM. Cette configuration n’est pas recommandée pour un serveur de production utilisé par plusieurs personnes.
Déploiements multiserveur
Les scénarios suivants peuvent nécessiter un déploiement sur plusieurs serveurs :
- Mise à l’échelle au-delà de 500 utilisateurs
- Utilisation intensive de la génération, du test ou de la mise en production automatisées
- Utilisation du code Recherche
- Utilisation des fonctionnalités de création de rapports
Pour une équipe de plus de 500 utilisateurs, envisagez la configuration suivante :
- Une couche Application avec un processeur double cœur, 8 Go de mémoire et un disque dur rapide.
- Un niveau données avec un processeur quatre cœurs, 16 Go de mémoire et un stockage hautes performances, tel qu’un disque SSD.
Pour une équipe de plus de 2 000 utilisateurs, envisagez la configuration suivante :
- Une couche Application avec un processeur quatre cœurs, 16 Go ou plus de mémoire et un disque dur rapide.
- Un niveau de données avec au moins deux processeurs quatre cœurs, 16 Go ou plus de mémoire et un stockage hautes performances avancé, comme un DISQUE SSD ou un SAN hautes performances.
Si vous envisagez d’utiliser l’automatisation de la génération, du test ou de la mise en production, nous vous recommandons d’utiliser les niveaux d’application et de données de spécifications supérieures pour éviter les problèmes de performances. Par exemple, une équipe de 250 personnes peut utiliser un déploiement sur plusieurs serveurs plus conforme aux recommandations pour une équipe de 500 à 2 000 utilisateurs. Nous vous recommandons également de surveiller vos processus automatisés pour vous assurer qu’ils sont efficaces. Par exemple, récupérez des données à partir du contrôle de code source de manière incrémentielle pendant les builds chaque fois que cela est possible au lieu d’une actualisation complète à chaque build.
Notes
À l’exception des très petites équipes qui utilisent très peu ces fonctionnalités, nous vous déconseillons d’installer des agents de build, de test ou de mise en production sur vos niveaux d’application Azure DevOps Server ou TFS.
Si vous envisagez d’utiliser Code Recherche, nous vous recommandons de configurer un serveur distinct pour Code Recherche. Pour plus d’informations, consultez la configuration matérielle requise pour Code Recherche.
Si vous envisagez d’utiliser des fonctionnalités de création de rapports, nous vous recommandons de configurer un serveur distinct pour votre base de données d’entrepôt et SQL Server Analysis Services cube. Une autre option consiste à utiliser un niveau de données de spécification plus élevé.
Si vous souhaitez garantir la haute disponibilité, envisagez d’utiliser plusieurs niveaux d’application derrière un équilibreur de charge et plusieurs instances SQL Server. Dans ce scénario, nous vous recommandons de placer vos bases de données Azure DevOps dans un groupe de disponibilité Always On.
Configuration matérielle requise pour le service de build
Le service de build XAML a la même configuration requise pour le système d’exploitation que Azure DevOps Server et TFS. En règle générale, il est judicieux d’exécuter le service de build sur un ordinateur distinct de la couche Application. La configuration matérielle requise pour le service de build est identique au système d’exploitation sur lequel il s’exécute. Cependant, vous pouvez personnaliser les performances du service de build en modifiant les spécifications matérielles de votre machine de build en fonction des types de build que votre équipe utilise.
Systèmes d’exploitation
Les systèmes d’exploitation suivants sont pris en charge pour les versions indiquées de Azure DevOps Server.
Installation du serveur ou du client
Azure DevOps Server s’exécute sur un système d’exploitation Windows Server ou un système d’exploitation client Windows et uniquement sur un système d’exploitation 64 bits. Nous vous recommandons d’utiliser un système d’exploitation serveur, sauf si votre Azure DevOps Server est à des fins d’évaluation ou d’utilisation personnelle.
Systèmes d’exploitation serveur
| Azure DevOps Serverversion | Systèmes d'exploitation serveurs pris en charge |
|---|---|
| Azure DevOps Server 2022 | Windows Server 2022 Windows Server 2019 |
| Azure DevOps Server 2020 | Windows Server 2019 Windows Server 2016 |
| Azure DevOps Server 2019 | Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 (Essentials, Standard, Datacenter) Windows Server 2012 (Essentials, Standard, Datacenter) |
| TFS 2018 | Windows Server 2016 Windows Server 2012 R2 (Essentials, Standard, Datacenter) Windows Server 2012 (Essentials, Standard, Datacenter) |
L’option d’installation server Core est prise en charge pour Azure DevOps Server 2022, Azure DevOps Server 2020, Azure DevOps Server 2019 et TFS 2018. Windows Server version 1709 n’est pas prise en charge.
Systèmes d'exploitation client
| version Azure DevOps Server | Systèmes d'exploitation clients pris en charge |
|---|---|
| Azure DevOps Server 2022 | Windows 11 version 21H2 Windows 10 1809 ou version ultérieure |
| Azure DevOps Server 2020 | Windows 10 (Enterprise) version 1803 Windows 10 (Professionnel, Entreprise) 1809 ou version ultérieure |
| Azure DevOps Server 2019 | Windows 10 (Professionnel, Entreprise) version 1607 ou ultérieure |
| TFS 2018 | Windows 10 (Professionnel, Entreprise) version 1607 ou ultérieure |
Bien que vous puissiez installer Azure DevOps Server sur un système d’exploitation client, nous ne recommandons pas l’installation du système d’exploitation client, sauf à des fins d’évaluation ou d’utilisation personnelle. Vous ne pouvez pas installer Azure DevOps Server proxy sur les systèmes d’exploitation clients.
Configuration requise pour le serveur proxy
Le serveur proxy n’est disponible que lorsque vous installez Azure DevOps Server sur un système d’exploitation Windows Server. Les systèmes pris en charge sont répertoriés dans le tableau suivant pour chaque version.
| Version du serveur proxy Azure DevOps | Systèmes de système d’exploitation Windows pris en charge |
|---|---|
| Serveur proxy Azure DevOps 2022 | Windows Server 2022 Windows Server 2019 Ordinateur Windows Server principal |
| Serveur proxy Azure DevOps 2020 | Windows Server 2019 Windows Server 2016 Ordinateur Windows Server principal |
| Serveur proxy Azure DevOps 2019 | Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 (Essentials, Standard, Datacenter) Windows Server 2012 (Essentials, Standard, Datacenter) Ordinateur Windows Server principal |
| Team Foundation Proxy Server 2018 | Windows Server 2016 Windows Server 2012 R2 (Essentials, Standard, Datacenter) Windows Server 2012 (Essentials, Standard, Datacenter) |
Passez en revue les recommandations matérielles suivantes pour déterminer le matériel optimal à utiliser pour Azure DevOps Server Proxy.
Contrairement à la configuration requise du système d’exploitation, les recommandations matérielles pour le proxy sont différentes des recommandations matérielles pour la configuration de la couche application de Azure DevOps Server. La couche Application nécessite un matériel plus robuste que le serveur proxy.
Le matériel recommandé est basé sur la taille de l’équipe qui utilisera le serveur proxy. En général, il s’agit de l’équipe de votre bureau distant. Plus votre équipe est grande, plus votre matériel doit être robuste.
| Taille de l’équipe distante | Recommandations matérielles (PROCESSEUR/RAM) pour Azure DevOps Server Proxy |
|---|---|
| 450 utilisateurs ou moins | Un processeur, processeur de 2,2 GHz, 4 Go de RAM |
| Entre 451 et 2 200 utilisateurs | Deux processeurs, processeur 2,0 GHz, 8 Go de RAM |
| Entre 2 201 et 3 600 utilisateurs | Quatre processeurs, processeur de 2,0 GHz, 8 Go de RAM |
Exigences supplémentaires du proxy GVFS
La fonctionnalité de proxy GVFS (Git Virtual File System) prend en charge les opérations intensives d’entrée/sortie (E/S). En plus des exigences de base pour Azure DevOps Server proxy, le proxy GVFS nécessite un disque rapide et volumineux pour fonctionner efficacement sur le dépôt. Le matériel recommandé est basé sur la taille du dépôt que le proxy GVFS sert.
| Matériel | Valeur recommandée |
|---|---|
| RAM | Aussi grande que l’extrémité d’une branche classique |
| Espace disque | Quatre fois la taille totale du dépôt |
| Matériel disque | Un disque SSD |
Par exemple, si un dépôt a 50 Go dans sa branche main et 200 Go d’historique, nous recommandons 50 Go de RAM et 800 Go de stockage SSD.
Virtualisation
Microsoft prend en charge la virtualisation Azure DevOps Server dans les environnements de virtualisation pris en charge.
Pour plus d’informations, consultez les articles suivants :
- Logiciels serveur Microsoft et environnements de virtualisation pris en charge
- Stratégie de prise en charge des logiciels Microsoft s’exécutant dans des logiciels de virtualisation matériels non Microsoft
- Partenaires de support pour les logiciels de virtualisation matériels autres que Microsoft
- Virtualisation de serveur (produits officiellement pris en charge)
Azure SQL Database et SQL Server
Les déploiements locaux d’Azure DevOps nécessitent une version de SQL Server. Azure DevOps Server prend en charge les éditions Express, Standard et Enterprise SQL Server. L’édition Express est recommandée uniquement à des fins d’évaluation, d’utilisation personnelle ou pour de très petites équipes. Nous recommandons les versions SQL Server Standard ou Entreprise pour tous les autres scénarios.
Pour les déploiements de production, utilisez l’une des versions suivantes de SQL Server.
| Version d’Azure DevOps | Version de SQL Server prises en charge |
|---|---|
| Azure DevOps Server 2022 | Azure SQL Database Azure SQL Managed Instance SQL Server 2022 SQL Server 2019 SQL Server 2017 |
| Azure DevOps Server 2020 | Azure SQL Database SQL Server 2019 SQL Server 2017 SQL Server 2016 (sp1 minimum) |
| Azure DevOps Server 2019 Update 1.1 | Azure SQL Database SQL Server 2019 SQL Server 2017 SQL Server 2016 (sp1 minimum) |
| Azure DevOps Server 2019 | Azure SQL Database SQL Server 2017 SQL Server 2016 (sp1 minimum) |
| TFS 2018 | SQL Server 2017 SQL Server 2016 (sp1 minimum) |
Notes
SQL Server sur Linux n’est pas pris en charge.
Les informations suivantes s’appliquent à la version SQL Server indiquée :
- Azure SQL Database : prise en charge uniquement lorsque vous utilisez également Azure Machines Virtuelles. Pour plus d’informations, consultez Utiliser Azure SQL database avec Azure DevOps Server.
- SQL Server 2016 : si vous utilisez SQL Server 2016, vous devez installer une mise à jour du runtime Visual C++.
Active Directory
Vous pouvez installer Azure DevOps sur plusieurs serveurs si les serveurs sont tous joints à un domaine Active Directory basé sur un niveau fonctionnel pris en charge par les serveurs. Vous pouvez installer Azure DevOps sur un serveur unique joint à un domaine Active Directory ou membre d’un groupe de travail.
Principales versions et Service Packs
Microsoft ne prend pas toujours en charge immédiatement les nouvelles versions majeures des dépendances telles que SQL Server. Parfois, nous devons publier des mises à jour pour ajouter la prise en charge de ces versions. Toutefois, lorsque Microsoft prend en charge une version majeure, nous prenons toujours en charge le dernier Service Pack dès sa publication. Nous travaillons avec les équipes de produits pour tester les Service Packs avant leur publication.
Langues naturelles
Vous pouvez installer Azure DevOps dans différents langages sur les systèmes d’exploitation pris en charge. Toutefois, vous ne pouvez pas utiliser une combinaison de système d’exploitation localisé avec Azure DevOps Server et TFS. En outre, vous ne pouvez pas installer plusieurs langues sur un seul serveur Azure DevOps Server ou TFS.
Le tableau suivant décrit les combinaisons de langues prises en charge :
| Système d’exploitation | Azure DevOps Server |
|---|---|
| Anglais | Anglais |
| Anglais | Langue autre que l'anglais |
| Langue autre que l'anglais | Anglais |
| Langue autre que l'anglais | La langue doit correspondre au système d'expression |
Si vous exécutez un système d’exploitation en anglais, vous pouvez installer n’importe quelle version linguistique de Azure DevOps Server. Si vous n’exécutez pas de système d’exploitation en anglais, vous devez installer la version anglaise de Azure DevOps Server ou la version qui a été localisée dans la même langue que le système d’exploitation.
Le serveur proxy Azure DevOps et les Explorer d’équipe n’ont pas d’exigences linguistiques supplémentaires spécifiques à l’utilisation de Azure DevOps Server.
Les contrôleurs et agents de test ont leurs propres spécifications linguistiques requises. Pour plus d’informations, consultez Configuration requise pour le contrôleur de test et l’agent de test.