Configuration requise pour Azure DevOps en 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 exigences fournies dans cet article.
En plus de ces exigences, consultez également les articles suivants :
- Compatibilité de build client et locale
- Exigences relatives au compte de service
- Vue d’ensemble de l’architecture
- Ports et protocoles réseau par défaut
- Paramètres réseau personnalisables
- Compatibilité des artefacts et des versions Azure
Recommandations matérielles
Azure DevOps local peut effectuer une mise à 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 à 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 référentiels Git particulièrement volumineux ou des branches TVC (Team Foundation version control), vous devrez peut-être des machines plus précises que celles répertoriées dans les sections suivantes. Toutes les machines décrites dans les sections suivantes peuvent être physiques ou virtuelles.
Déploiement à un seul serveur
Un déploiement à serveur unique se compose d’une seule machine avec un processeur double cœur, 4 Go de RAM et un disque dur rapide. Pour la recherche élastique, 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 des fonctionnalités de suivi des éléments de travail. Une utilisation étendue de la build, du test ou de la mise en production automatisée entraîne 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 build, 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 monter en puissance 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 à plusieurs serveurs :
- Mise à l’échelle au-delà de 500 utilisateurs
- Utilisation étendue de la build, du test ou de la mise en production automatisées
- Utilisation de la recherche de code
- Utilisation des fonctionnalités de création de rapports
Pour une équipe de plus de 500 utilisateurs, tenez compte de la configuration suivante :
- Couche Application avec un processeur double cœur, 8 Go de mémoire et un disque dur rapide.
- Niveau de 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, tenez compte de la configuration suivante :
- Couche Application avec un processeur à quatre cœurs, 16 Go ou plus de mémoire et un disque dur rapide.
- 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é, tel qu’un DISQUE SSD ou un SAN hautes performances.
Si vous envisagez d’utiliser l’automatisation de build, de test ou de mise en production en grande partie, nous vous recommandons d’utiliser des niveaux d’application et de données plus élevés pour éviter les problèmes de performances. Par exemple, une équipe de 250 peut utiliser un déploiement à plusieurs serveurs plus conforme aux recommandations d’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 au lieu d’être entièrement actualisées avec chaque build.
Remarque
À l’exception des très petites équipes qui ont une utilisation extrêmement limitée de 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 la recherche de code, nous vous recommandons de configurer un serveur distinct pour la recherche de code. Pour plus d’informations, consultez la configuration matérielle requise pour la recherche de code.
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 le cube SQL Server Analysis Services. Une autre option consiste à utiliser un niveau de données de spécification supérieur.
Si vous souhaitez garantir une 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 du service de génération
Le service de build XAML a la même configuration requise pour le système d’exploitation qu’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 elle est en cours d’exécution. Toutefois, vous pouvez optimiser les performances du service de génération en adaptant les spécifications matérielles de votre machine de build aux types de builds que votre équipe utilisera.
Systèmes d’exploitation
Les systèmes d’exploitation suivants sont pris en charge pour les versions indiquées d’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 serveur Azure DevOps est à des fins d’évaluation ou d’utilisation personnelle.
Systèmes d’exploitation serveurs
| 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 pris en charge.
Systèmes d’exploitation clients
| Version d'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 (Entreprise) 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 vous déconseillons d’installer le système d’exploitation client à l’exception d’une utilisation personnelle ou à des fins d’évaluation. Vous ne pouvez pas installer le proxy Azure DevOps Server sur les systèmes d’exploitation clients.
Configuration requise pour le serveur proxy
Le serveur proxy est disponible uniquement 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 d’exploitation Windows pris en charge |
|---|---|
| Serveur proxy Azure DevOps 2022 | Windows Server 2022 Windows Server 2019 Windows Server Core |
| Serveur proxy Azure DevOps 2020 | Windows Server 2019 Windows Server 2016 Windows Server Core |
| Serveur proxy Azure DevOps 2019 | Windows Server 2019 Windows Server 2016 Windows Server 2012 R2 (Essentials, Standard, Datacenter) Windows Server 2012 (Essentials, Standard, Datacenter) Windows Server Core |
| 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 le proxy de serveur Azure DevOps.
Contrairement à la configuration requise du système d’exploitation, les recommandations matérielles pour le proxy diffèrent des recommandations matérielles pour la configuration du niveau d’application d’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 règle générale, il s’agit de l’équipe de votre bureau à distance. Plus votre équipe est grande, plus votre matériel doit être robuste.
| Taille de l’équipe distante | Recommandations matérielles (PROCESSEUR/RAM) pour le proxy de serveur Azure DevOps |
|---|---|
| 450 utilisateurs ou moins | Un processeur, processeur de 2,2 GHz, 4 Go de RAM |
| Entre 451 et 2 200 utilisateurs | Deux processeurs, processeur de 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 |
Conditions supplémentaires requises pour le proxy GVFS
La fonctionnalité de proxy GVFS (Git Virtual File System) prend en charge les opérations d’entrée/sortie intensives (E/S). Outre les exigences de base pour le proxy de serveur Azure DevOps, le proxy GVFS nécessite un disque rapide et volumineux pour fonctionner efficacement sur le référentiel. Le matériel recommandé est basé sur la taille du référentiel utilisé par le proxy GVFS.
| Matériel | Valeur recommandée |
|---|---|
| RAM | Aussi grand que l’extrémité d’une branche classique |
| Espace disque | Quatre fois la taille entière du référentiel |
| Matériel disque | Un lecteur SSD (SOLID-State Drive) |
Par exemple, si un référentiel a 50 Go dans sa branche principale et 200 Go d’historique, nous vous recommandons de 50 Go de RAM et de 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 :
- Produits serveur Microsoft et environnements de virtualisation pris en charge
- Stratégie de support pour les logiciels Microsoft s’exécutant dans des logiciels de virtualisation matérielle non-Microsoft
- Prise en charge des partenaires pour les logiciels de virtualisation matérielle non-Microsoft
- Virtualisation de serveur (produits officiellement pris en charge)
Azure SQL Database et SQL Server
Les déploiements locaux 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 vous recommandons les versions SQL Server Standard ou Enterprise 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 |
| 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) |
Remarque
SQL Server sur Linux n’est pas pris en charge.
Les informations suivantes s’appliquent à la version indiquée de SQL Server :
- Azure SQL Database : uniquement pris en charge 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.
Versions majeures et service packs
Microsoft ne prend pas toujours en charge immédiatement les nouvelles versions majeures des dépendances comme 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 immédiatement lorsqu’il est publié. 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 de combinaison de système d’exploitation localisé avec Azure DevOps Server et TFS. En outre, vous ne pouvez pas installer plusieurs langues sur un serveur Azure DevOps ou un serveur TFS unique.
Le tableau suivant présente les combinaisons linguistiques 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’exploitation |
Si vous exécutez un système d’exploitation en langue anglaise, vous pouvez installer n’importe quelle version linguistique d’Azure DevOps Server. Si vous n’exécutez pas de système d’exploitation en langue anglaise, vous devez installer la version anglaise d’Azure DevOps Server ou la version localisée pour la même langue que le système d’exploitation.
Le serveur proxy Azure DevOps et l’Explorateur d’équipes n’ont pas de conditions linguistiques supplémentaires spécifiques à l’utilisation d’Azure DevOps Server.
Les contrôleurs de test et les agents ont leurs propres exigences linguistiques. Pour plus d’informations, consultez La configuration requise pour le contrôleur de test et l’agent de test.