Contexte de la surcharge
En septembre 2026, GitHub a enregistré 7,38 milliards de commits, soit plus de cinq fois le volume de l’année précédente. Le nombre d’événements Git mensuels est passé de 218,2 milliards en septembre 2025 à 473,3 milliards en août 2026. Les pushes mensuels ont crû de 0,69 milliard à 3,35 milliard (augmentation de 4,9 ×) et les merges de pull‑request ont presque quadruplé. Cette explosion provient des agents de codage automatisés qui créent, poussent et déclenchent des pipelines à chaque itération, dépassant largement le rythme humain prévu par les systèmes de stockage Git traditionnels.
Limites de l’architecture Spokes
L’infrastructure actuelle, nommée Spokes, conserve cinq copies complètes de chaque dépôt sur des serveurs locaux et utilise un protocole de commit en trois phases pour garantir la cohérence. Cette redondance assure une forte durabilité, mais elle lie directement les lectures aux écritures : « Chaque réplique participe à chaque écriture, donc un push n’est aussi rapide que la réplique la plus lente ». Ajouter des répliques pour absorber la charge de lecture ralentit donc les écritures, un compromis qui devient critique lorsque des milliers d’agents génèrent des pushes simultanés. De plus, les tâches de maintenance (compaction, garbage collection) s’accumulent à mesure que le volume augmente, et les pipelines CI qui clonent le dépôt amplifient la pression en créant des rafales de lectures.
Nouvelle architecture basée sur Azure Blob
GitHub a donc séparé le stockage de la couche de calcul. Les données de référence du dépôt sont désormais stockées dans Azure Blob Storage, qui fournit durabilité et réplication à l’échelle du cloud Azure. Des compute workers légers se placent devant ce stockage et mettent en cache les objets demandés. Cette approche permet d’ajouter ou de retirer des workers sans toucher à la durabilité des données : une défaillance d’un worker n’entraîne qu’un « cache miss », pas une perte de réplica. GitHub indique que les benchmarks internes montrent jusqu’à 35 fois plus de débit d’écriture comparé à l’ancien modèle. Les mises à jour de références (déplacement d’un pointeur de branche) restent le seul point nécessitant un accord global, tandis que la vérification de secrets, la connectivité et les tâches de maintenance s’exécutent de façon indépendante.
Implications pour les équipes DevOps
Si les pushes s’accélèrent, le goulot d’étranglement se déplace vers les revues de code et les protections de branche, qui fonctionnent toujours à vitesse humaine. Mitch Ashley souligne que les agents créent une « dette de vérification » plus rapide que les équipes ne peuvent la résoudre, augmentant les coûts CI et les risques de défauts non détectés. Les organisations doivent donc identifier où la latence de push, les tempêtes de clones et la contention sur une branche unique impactent leurs pipelines internes. Repenser la granularité des commits d’agents, regrouper les checkpoints ou ajuster les politiques de merge devient indispensable pour éviter des pannes liées à la surcharge du système de versionnage.
