Pourquoi passer à Azure DevOps Server maintenant ?

Une plateforme DevOps on-premise fonctionne bien seulement si trois bases sont en place dès le début.

1. Un accès sécurisé en HTTPS.
2. Les sauvegardes automatiques doivent être testées.
3. Les agents de build doivent tourner sans intervention.

Petite précision de vocabulaire d'abord. Ce que beaucoup appellent encore « Azure DevOps Server 2025 » s'appelle officiellement Azure DevOps Server, sans millésime. La version finale est sortie le 9 décembre 2025, et Microsoft a abandonné l'année dans le nom pour éviter toute confusion sur la version courante.

Ce changement n'est pas que cosmétique :

• Fin du cycle de deux ans. Le produit passe sous la Modern Lifecycle Policy : une seule version, mise à jour en continu, supportée tant que vous appliquez les correctifs.
• Fin de support des anciennes versions. TFS 2015 a perdu son support étendu le 14 octobre 2025, et le support standard d'Azure DevOps Server 2020 s'est arrêté le même jour.
• Mise à niveau directe. Toute version depuis TFS 2015 peut être mise à niveau directement.

C'est le moment idéal pour moderniser l'usine logicielle sans passer au cloud, pour les organisations soumises à des contraintes de souveraineté, de résidence des données ou d'isolement réseau.

Au menu : prérequis, installation neuve ou migration, configuration HTTPS avec certificat, sauvegardes planifiées, puis installation des agents de build Windows et Linux.

Architecture cible : serveur apptiers, serveur SQL, 2 serveurs pools d'agents

Les agents ouvrent eux-mêmes la connexion vers le serveur en HTTPS : aucun port entrant n'est nécessaire sur les machines de build.

1. Les prérequis à valider avant de commencer

La nouvelle version exige Windows Server 2022 ou 2025 et SQL Server 2022 ou 2025 : un serveur TFS ou ADS 2022 sur Windows Server 2019 ou SQL Server 2019 devra donc être monté en version avant ou pendant la migration.

À préparer en amont :

• Un nom DNS définitif, par exemple devops.mondomaine.com, plutôt que le nom de la machine. Il survivra à un changement de serveur.
• Les comptes des services pour le service applicatif et les agents (par exemple svc-devops et svc-agents) avec droits d'administrateur.
• Le certificat TLS couvrant ce nom DNS, au format .pfx avec sa clé privée.
• Un partage réseau pour les sauvegardes, sur un autre serveur ou un NAS.
• Les ports ouverts : 443 vers le serveur depuis les postes et les agents, 1433 entre le serveur applicatif et SQL Server s'ils sont séparés.

2. Installation neuve ou migration : choisir le bon scénario

Trois chemins mènent à Azure DevOps Server, et le choix dépend surtout de votre point de départ et de l'âge de votre serveur actuel.

Scénario A : installation neuve

1. Installez SQL Server 2022 ou 2025 (Standard ou Enterprise), service Database Engine et Full-Text Search.
2. Téléchargez Azure DevOps Server depuis la page de téléchargement Microsoft, puis lancez l'installateur.
3. À la fin de l'installation, le Centre de configuration s'ouvre. Choisissez Nouveau déploiement - Avancé pour garder la main sur chaque paramètre.
4. Indiquez l'instance SQL Server et le compte de service MONDOMAINE\svc-devops.
5. Sur la page Niveau application, choisissez le groupe de paramètres HTTPS et HTTP (avec redirection), sélectionnez votre certificat importé et saisissez l'URL publique https://devops.mondomaine.com.
6. Laissez l'assistant créer la collection par défaut, puis lancez les vérifications de disponibilité et la configuration.

Scénario B : mise à niveau sur place

1. Faites une sauvegarde complète de toutes les bases (configuration et collections) depuis la console d'administration, et vérifiez qu'elle est lisible.
2. Lancez l'installateur de la nouvelle version sur le serveur existant. Il remplace les binaires.
3. Le Centre de configuration propose l'assistant Mise à niveau. Sélectionnez la base de configuration, gardez le même compte de service et validez.
4. Selon la taille des collections, comptez de quelques minutes à plusieurs heures. Ne coupez jamais le serveur pendant cette étape.

Scénario C : migration sur un nouveau serveur (le plus fréquent)

C'est la méthode que nous recommandons, dès que l'ancien serveur a plus de trois ans : vous repartez sur un OS propre, et l'ancien serveur reste disponible pour un retour arrière.

1. Répétition générale. Restaurez une copie des bases sur un serveur de test et lancez l'assistant de mise à niveau en mode Pré-production. Ce mode change les identifiants du serveur pour qu'il ne se confonde pas avec la production. Mesurez la durée.
2. Préparez les nouveaux serveurs. Windows Server 2025, SQL Server 2025 et Azure DevOps Server installé mais non configuré : fermez le Centre de configuration à la fin de l'installation.
3. Gelez l'ancien serveur. Annoncez une fenêtre de maintenance, puis arrêtez l'accès utilisateur :
4. Sauvegardez toutes les bases depuis l'ancienne console (Sauvegardes planifiées > Effectuer une sauvegarde complète maintenant) vers un partage accessible par le nouveau serveur.
5. Restaurez sur le nouveau serveur : console d'administration > Sauvegardes planifiées > Restaurer les bases de données, choisissez le jeu de sauvegarde et l'instance SQL cible.
6. Mettez à niveau. Ouvrez le Centre de configuration, choisissez Mise à niveau, mode Production, et pointez sur la base de configuration restaurée.
7. Basculez le DNS. Faites pointer devops.mondomaine.com vers le nouveau serveur. Si les utilisateurs et les agents utilisaient déjà ce nom, ils ne verront qu'une coupure.
8. Désactivez l'ancien serveur (services arrêtés) sans le supprimer pendant au moins deux semaines.

3. Sécuriser l'accès en HTTPS avec un certificat

L'objectif est simple : une seule adresse https://devops.mondomaine.com, servie par un certificat de confiance, avec redirection automatique depuis HTTP. Si vous avez choisi le groupe HTTPS dans l'assistant (scénario A, étape 5), il ne reste qu'à vérifier ; sinon, voici la procédure complète.

Étape 1 : obtenir le bon certificat

Le certificat doit contenir le nom DNS public dans son Subject Alternative Name (SAN), et pas seulement dans le Common Name. Importez-le avec sa clé privée dans le magasin de l'ordinateur :

Étape 2 : ajouter la liaison HTTPS dans IIS

1. Ouvrez le Gestionnaire IIS, site Azure DevOps Server, puis Liaisons….
2. Ajoutez une liaison https, port 443, nom d'hôte devops.mondomaine.com, cochez Exiger l'indication du nom de serveur (SNI) et sélectionnez le certificat.
3. Gardez temporairement la liaison HTTP existante pour ne pas couper les utilisateurs pendant la bascule.

Étape 3 : changer l'URL publique

1. Ouvrez la Console d'administration Azure DevOps Server, nœud Niveau application.
2. Cliquez sur Modifier l'URL publique et saisissez https://devops.mondomaine.com/.
3. Testez l'URL depuis la boîte de dialogue, puis validez. Les e-mails de notification, les liens des work items et les agents utiliseront désormais cette adresse.

Étape 4 : forcer HTTPS et durcir TLS

• Remplacez la liaison HTTP par une redirection permanente vers HTTPS, ou supprimez-la si aucun ancien client n'en dépend. Microsoft déconseille de garder une URL publique en HTTP avec HTTPS actif : les navigateurs bloquent le contenu mixte.
• Désactivez TLS 1.0 et 1.1 au niveau de Windows et gardez TLS 1.2 et 1.3. Un outil comme IIS Crypto simplifie ce réglage.
• Ouvrez le port 443 dans le pare-feu Windows et fermez le port 8080 historique s'il n'est plus utilisé.

Étape 5 : vérifier

• Le navigateur affiche le cadenas sans avertissement, depuis un poste du domaine et depuis un poste hors domaine.
• Un git clone https://devops.mondomaine.com/DefaultCollection/MonProjet/_git/MonDepot fonctionne. Sous Windows, si vous utilisez une PKI interne, la commande suivante permet à Git d'utiliser le magasin de certificats Windows :

• Visual Studio se reconnecte avec la nouvelle URL.
• Une alerte e-mail de test contient bien des liens en https://.

Pensez enfin à inscrire la date d'expiration du certificat dans votre outil de supervision : un certificat expiré arrête d'un coup les builds, les clones Git et l'accès web.

4. Mettre en place des sauvegardes planifiées

Toute la valeur d'Azure DevOps Server réside dans ses bases SQL : code source, éléments de travail, historique des builds, artefacts. L'outil Sauvegardes planifiées de la console d'administration les sauvegarde de façon cohérente, configuration et collections en même temps, ce qu'un plan de maintenance SQL classique ne garantit pas.

Préparer les droits

• Le compte de service Azure DevOps doit avoir sur l'instance SQL les droits Effectuer une sauvegarde et Créer un plan de maintenance.
• Le compte de service et l'administrateur qui configure le plan doivent avoir le Contrôle total sur le partage réseau de destination, par exemple \\nas01\backups-devops.
• Pour recevoir des alertes, configurez d'abord le serveur SMTP dans la console (nœud Niveau application > Paramètres d'alerte e-mail). Sans SMTP, les options d'alerte de l'assistant restent grisées.

Lancer l'assistant

1. Console d'administration > Sauvegardes planifiées > Créer une planification de sauvegarde.
2. Chemin réseau : indiquez le partage UNC et la durée de rétention des jeux de sauvegarde, par exemple 30 jours.
3. Alertes : cochez au minimum l'échec de sauvegarde, et envoyez-les à une liste de diffusion plutôt qu'à une personne.
4. Planification : choisissez l'un des deux modèles proposés ou une planification personnalisée. Le tableau ci-dessous donne notre réglage de référence.
5. Terminez l'assistant, puis lancez immédiatement Effectuer une sauvegarde complète maintenant pour disposer d'un premier point de restauration.

Les trois pièges à éviter

1. Sauvegarder sur le même serveur. Si le disque ou la machine tombe, sauvegarde et production disparaissent ensemble. Copiez aussi le partage hors site ou vers un stockage objet.
2. Changer d'édition SQL. Si vous sauvegardez depuis SQL Server Enterprise et prévoyez de restaurer sur une édition Standard, désactivez la compression des données SQL avant la sauvegarde, comme l'indique Microsoft.

5. Installer les agents de build Windows et Linux

En mode on-premise, il n'y a aucun agent hébergé par Microsoft, chaque pipeline tourne sur vos propres machines. Nous vous conseillons de prévoir au moins deux pools, un pool Windows pour .NET Framework et les projets Visual Studio et un Linux pour les conteneurs Docker, le front-end et le .NET moderne.

Préparation commune

1. Créez les pools. Paramètres de la collection > Pools d'agents > Ajouter un pool > Auto-hébergé, par exemple Build-Windows et Build-Linux.
2. Créez un jeton d'accès personnel (PAT) avec l'étendue Agent Pools (Read & manage) et une courte durée de vie. Il ne sert qu'à l'enregistrement : l'agent utilise ensuite son propre jeton.
3. Téléchargez l'agent depuis votre serveur (bouton Nouvel agent dans le pool). Vous obtenez ainsi une version d'agent compatible avec votre version d'Azure DevOps Server.
4. Retenez l'URL de collection : https://devops.mondomaine.com/DefaultCollection.

Agent Windows

Sur un Windows Server 2022 ou 2025 avec les SDK .NET, Git et les Build Tools de Visual Studio installés, ouvrez PowerShell en administrateur :

• Le service s'installe sous le nom vstsagent.devops.Build-Windows.Build-Windows et démarre automatiquement.
• Utilisez un compte de domaine dédié (svc-build) plutôt que Network Service si vos builds accèdent à des partages ou à des bases SQL.
• Gardez des chemins courts (C:\agents\...) : certains projets .NET Framework dépassent la limite des 260 caractères.

Agent Linux

Sur Ubuntu 22.04 ou 24.04 (ou RHEL 9), créez un utilisateur dédié : l'agent refuse de s'exécuter en root.

L'agent tourne alors comme service systemd et redémarre avec la machine.

Le piège n°1 sous Linux : le certificat

Un poste Windows du domaine fait déjà confiance à votre PKI interne, une machine Linux non. Sans cette confiance, config.sh et les git clone échouent avec une erreur SSL. Deux solutions propres :

1. Ajouter l'autorité racine au système (recommandé) :

2. La passer à l'agent lors de la configuration avec --sslcacert ca-mondomaine.pem.

Valider avec un premier pipeline

Ce pipeline lance un job sur chaque pool et confirme que tout répond :

Pour aller plus loin, ajoutez des capacités personnalisées (par exemple java=17) et des demands dans vos pipelines pour orienter chaque job vers la bonne machine.

6. Checklist de mise en production

Avant d'annoncer l'ouverture aux équipes, cochez chaque ligne :

• La console d'administration affiche l'URL publique en https:// et le site répond sans avertissement.
• TLS 1.0 et 1.1 sont désactivés ; HTTP redirige vers HTTPS.
• La date d'expiration du certificat est suivie dans la supervision.
• Une sauvegarde complète a réussi et ses fichiers sont visibles sur le partage.
• Une restauration de test a été menée au moins une fois.
• Les alertes e-mail d'échec de sauvegarde arrivent sur une liste de diffusion.
• Chaque pool contient au moins deux agents en ligne, pour éviter le point unique de défaillance.
• Le pipeline de test passe sur les pools Windows et Linux.
• Les PAT d'enregistrement des agents ont été révoqués.

Conclusion : une usine logicielle souveraine, sécurisée et automatisée

Avec son accès HTTPS sécurisé, ses sauvegardes éprouvées et ses agents Windows et Linux dédiés, votre Azure DevOps Server est prêt à accueillir vos projets pour les années à venir, surtout depuis que le nouveau modèle de mises à jour continues supprime les grandes migrations tous les deux ans.

Besoin d'aide pour aller plus vite ? Artza Technologies vous accompagne à chaque étape :

• Formation de vos administrateurs et développeurs à Azure DevOps Server et Azure Pipelines (YAML, agents, sécurité).
• Accompagnement à la migration depuis TFS, Azure DevOps Server 2019 à 2022 ou Azure DevOps Services, avec répétition générale et plan de retour arrière.
• Développement .NET agile en nearshore depuis le Maroc, avec des pipelines CI/CD prêts dès le premier sprint.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Le champ est obligatoire

Votre commentaire a bien été envoyé !

L'adresse électronique n'est pas valide

Envoyer