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.

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

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

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.

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.

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.

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.

Virtualization

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 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.

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 :

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.

Articles connexes

• 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