Microsoft AZ-400: Gestion du code source et des dépôts — Guide d'étude

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fait partie du Microsoft DevOps Engineer Expert AZ-400 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Les pratiques DevOps modernes reposent sur un contrôle de code source prévisible et collaboratif et sur une gestion de référentiel disciplinée. Azure Repos et GitHub fournissent des capacités complémentaires pour le contrôle de version, l’application des politiques, la collaboration et la sécurité. La maîtrise des stratégies de branche, des workflows de pull request, des autorisations, des hooks, de la gestion des fichiers volumineux, des modèles de migration, de l’analyse de sécurité et du versionnage est essentielle pour des pipelines de livraison résilients et une auditabilité. L’objectif n’est pas seulement de stocker du code, mais de créer un système de contrôles automatisé et exécutoire qui augmente le débit de l’équipe sans sacrifier la qualité.

Fondements du contrôle de code source dans Azure Repos et GitHub

Azure Repos prend en charge Git et Team Foundation Version Control (TFVC). Git est distribué, permet les commits locaux, la création de branches facile et des workflows décentralisés. TFVC est centralisé avec un versionnage côté serveur, des extractions verrouillées (facultatives), et est bien adapté aux solutions héritées avec de très gros actifs binaires ou aux équipes formées sur des workflows centralisés. Les nouveaux développements devraient utiliser Git par défaut ; TFVC reste viable lorsque le contrôle incrémental des changements et les autorisations centrales sont primordiaux et que le coût de migration est prohibitif.

Choisissez une stratégie de branchement de manière délibérée :

Le développement basé sur le tronc (trunk-based) favorise une seule branche principale à longue durée de vie avec des branches de fonctionnalités à très courte durée de vie et une intégration continue. Cela accélère le flux, réduit la dette de fusion et est idéal pour les équipes à haute cadence avec une forte automatisation des tests.
GitFlow utilise des branches develop et main (release) à longue durée de vie, avec des branches de fonctionnalité, de release et de hotfix. Il convient aux produits avec des cycles de livraison formels et des besoins de backporting, mais ajoute une surcharge de coordination.
GitHub Flow est un modèle simplifié avec une seule branche principale, des branches de sujet à courte durée de vie, un déploiement continu et des livraisons fréquentes. Il est efficace pour les services qui sont livrés en continu.

Monorepo versus multi-repo est principalement un choix d’organisation et d’outillage :

Le monorepo consolide de nombreux composants dans un seul référentiel, facilitant les changements atomiques inter-services, le refactoring unifié et l’outillage partagé. Il peut mettre à rude épreuve les opérations Git à mesure que l’historique s’allonge. Les techniques d’atténuation incluent le sparse checkout, le partial clone et les filtres de chemin CI pour limiter la portée des builds et des tests.
Le multi-repo isole la propriété, l’historique et les limites d’autorisation, facilitant le versionnage et la rétention indépendants. Il peut augmenter la coordination entre les référentiels et la dérive des dépendances ; les sous-modules ou les gestionnaires de dépendances et l’orchestration des livraisons sont essentiels.

La propriété et le routage des changements bénéficient des déclarations de propriété du code. Le fichier CODEOWNERS de GitHub associe automatiquement les chemins aux réviseurs obligatoires. Dans Azure Repos, utilisez les réviseurs requis basés sur le chemin dans les politiques de branche (et CODEOWNERS s’il est activé) pour acheminer les révisions vers les équipes de composants. Complétez la propriété avec des conventions de nommage de branche, des messages de commit clairs (par ex., Conventional Commits) et des modèles de référentiel pour la cohérence.

Gouvernance : Politiques, autorisations et pull requests

Les politiques de branche dans Azure Repos codifient les portails de qualité (quality gates) :

Les réviseurs requis imposent un nombre minimum de réviseurs et peuvent inclure des individus/groupes spécifiques ou des auto-réviseurs basés sur le chemin. Exigez la résolution des commentaires pour garantir que les retours de fond sont traités avant la fusion.
La validation de build nécessite qu’un ou plusieurs pipelines CI réussissent avant la fusion. Utilisez des filtres de chemin pour éviter les builds inutiles et configurez le déclenchement automatique sur les nouvelles mises à jour. Intégrez des vérifications externes via des politiques de statut pour les analyses de sécurité ou les tests de performance.
Les stratégies de fusion peuvent être contraintes : Merge (no fast-forward) enregistre l’historique de la fusion ; Squash condense les changements en un seul commit, gardant l’historique linéaire ; Rebase and fast-forward réécrit la branche de sujet sur la branche principale pour un historique rectiligne ; Rebase and merge rejoue les commits et préserve les commits séparés sans commit de fusion. Alignez la stratégie sur les besoins d’audit et l’outillage en aval.
Les vérifications supplémentaires incluent les éléments de travail liés requis, un nombre minimum de votes positifs et le blocage en cas de commentaires actifs ou de réviseurs en attente.

Les pull requests orchestrent la conversation d’intégration :

Les PR en mode brouillon (Draft) signalent un travail en cours et bloquent la finalisation jusqu’à ce qu’elles soient marquées comme prêtes. Encouragez les retours précoces sans déclencher prématurément les politiques.
L’auto-complétion fusionne automatiquement une fois que toutes les politiques sont respectées, réduisant la latence de coordination et augmentant le flux.
Le contournement des politiques (Bypass policies) existe pour les situations d’urgence ou les comptes d’automatisation. Verrouillez cette possibilité avec l’autorisation « Contourner les politiques lors de la finalisation des pull requests » et auditez-la via les approbations et la gestion des changements.
Les modèles de PR standardisent le contexte : preuves de test, notes de risque, étapes de déploiement et plan de retour en arrière. Dans Azure Repos, placez pull_request_template.md à la racine du référentiel ou dans .azuredevops/. Fournissez des listes de contrôle pour la sécurité, la performance et la documentation.

Les autorisations et les branches protégées sont votre dernière ligne de défense :

Utilisez les groupes RBAC d’Azure DevOps (Project Administrators, Contributors, Readers) et les autorisations de référentiel affinées (Create branch, Create tag, Contribute, Force push, Manage permissions, Bypass policies). Préférez les autorisations allow/deny sur les groupes plutôt que sur les individus.
Protégez les branches main et de release en interdisant le Force push et la suppression (Delete), en limitant la contribution (Contribute) aux seules fusions de PR, et en activant les politiques de branche qui exigent des builds et des révisions. Envisagez le « Verrouillage » (Lock) pour geler temporairement les changements.
Utilisez les autorisations au niveau de la branche pour restreindre qui peut créer ou finaliser des PR sur des branches sensibles, et séparez les tâches entre les développeurs et les responsables des livraisons (release managers).

Automatisation, Hooks, Fichiers Volumineux et Sécurité

Les hooks Git renforcent la qualité en amont :

Les hooks de pre-commit appliquent localement le linting, le formatage, la vérification des secrets et les tests unitaires avant qu’un développeur n’enregistre un commit. Gardez-les rapides et déterministes.
Les hooks de pre-push bloquent la publication (push) de code qui échoue aux tests d’intégration ou aux vérifications de politique. Fournissez des scripts de hooks à l’échelle de l’équipe via des outils (par ex., Husky pour JavaScript) et documentez l’adhésion volontaire (opt-in).
Les hooks côté serveur dans les services managés diffèrent : GitHub prend en charge les webhooks serveur et les vérifications de statut requises ; Azure DevOps Services n’autorise pas les hooks personnalisés côté serveur mais prend en charge les politiques de branche, les validations de build, les service hooks et les vérifications de statut provenant de systèmes externes. Dans Azure DevOps Server (on-prem), les hooks serveur sont possibles.

Large File Storage (Git LFS) stocke les gros fichiers binaires en dehors de la base de données d’objets Git, maintenant ainsi la performance du dépôt :

Suivez des modèles avec

undefined

ou des types de fichiers binaires spécifiques. Commitez le fichier .gitattributes pour que tous les contributeurs appliquent LFS de manière cohérente.

Migrez l’historique en exécutant

undefined

avec des filtres de chemin pour réécrire les gros binaires en pointeurs. Coordonnez-vous avec l’équipe et mettez les pushes en pause ; utilisez le force-push avec prudence et mettez à jour les clones.

Gérez la bande passante en évitant le « smudging » (téléchargement des fichiers LFS) inutile. Utilisez

undefined

et exécutez

undefined

de manière sélective. Mettez en cache LFS dans la CI et envisagez d’utiliser des dépôts d’artefacts pour les binaires qui n’ont pas besoin de résider dans Git.

L’assurance sécurité doit être de type « shift-left » (déplacée en amont) et basée sur des politiques :

GitHub Advanced Security (GHAS) apporte l’analyse de secrets (y compris la protection des pushes), l’analyse de code avec CodeQL et la revue des dépendances pour détecter les identifiants exposés, les vulnérabilités de code et les risques de la chaîne d’approvisionnement. Appliquez-les en tant que vérifications requises sur les PRs. Pour Azure Repos, utilisez Advanced Security for Azure DevOps pour obtenir des fonctionnalités similaires d’analyse de secrets, de SAST via CodeQL et d’informations sur les dépendances.
L’analyse de secrets doit être configurée pour bloquer les pushes contenant des secrets à haute confiance et pour alerter les équipes de sécurité. Prenez en charge les détecteurs personnalisés pour les modèles spécifiques à l’organisation.
L’analyse de code CodeQL doit s’exécuter sur les déclencheurs pull_request et schedule, en téléchargeant les résultats SARIF en tant que vérifications de statut. Ajustez les packs de requêtes pour réduire le bruit et garantir la couverture des chemins critiques.
La revue des dépendances met en évidence les changements de version et les avis de sécurité connus lors de la revue de PR ; utilisez-la pour les SLAs de remédiation et la gouvernance des licences.

Tous les domaines · Pipelines CI →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →