Comment déployer la plus grande instance GitLab 12 fois par jour

Chaque jour, GitLab déploie des modifications de code sur GitLab.com, la plus grande instance GitLab au monde, et ce jusqu'à 12 fois sans aucun temps d'arrêt. Nous utilisons la plateforme CI/CD de GitLab elle-même afin de gérer ces déploiements qui impactent des millions d'équipes de développement à travers le monde. Cette fréquence de déploiement constitue notre principal critère de qualité et notre test de charge. Résultat : nos clients profitent des nouvelles fonctionnalités quelques heures seulement après leur développement au lieu d'attendre des semaines ou des mois. Lorsque des organisations s'appuient sur GitLab pour leurs workflows DevOps, elles utilisent une plateforme évolutive et éprouvée.

Dans cet article, vous découvrirez comment nous avons construit un pipeline de déploiement automatisé en utilisant les fonctionnalités principales de GitLab CI/CD afin de gérer cette complexité de déploiement.

L'impératif métier de la vélocité de déploiement

Pour GitLab, la fréquence de déploiement ne représente pas simplement un indicateur technique, il s'agit au contraire d'un impératif métier. Des cycles de déploiement rapides nous permettent de répondre aux retours clients en quelques heures, de déployer immédiatement des correctifs de sécurité et de valider les nouvelles fonctionnalités en production avant de les déployer à grande échelle.

Pour nos clients, chaque déploiement vers GitLab.com valide les pratiques de déploiement que nous recommandons à nos utilisateurs. Lorsque vous utilisez les fonctionnalités de déploiement de GitLab, vous utilisez la même approche éprouvée qui gère quotidiennement des millions d'opérations git, de pipelines CI/CD et d'interactions utilisateurs. Vous bénéficiez ainsi des avantages suivants :

• Disponibilité immédiate des dernières fonctionnalités : les nouvelles fonctionnalités vous parviennent quelques heures après leur finalisation, et non dans des cycles trimestriels.
• Fiabilité éprouvée à grande échelle : si une fonctionnalité fonctionne sur GitLab.com, il en ira de même pour votre environnement.
• Valeur complète de GitLab : les déploiements sans interruption garantissent un accès constant à votre plateforme DevOps, même pendant les mises à jour.
• Pratiques testées en conditions réelles : notre documentation de déploiement ne relève pas de la théorie et reflète exactement la manière dont nous exploitons la plus grande instance GitLab existante.

Architecture du flux de code

Notre pipeline de déploiement suit une progression structurée à travers plusieurs étapes, chacune agissant comme un point de contrôle sur le parcours allant de la proposition de code au déploiement en production.

  graph TD
      A[Code proposé] --> B[Merge request créée]
      B --> C[Pipeline déclenché]
      C --> D[Build et test]
      D --> E{Spécifications/intégration/tests QA réussis ?}
      E -->|Non| F[Boucle de rétroaction]
      F --> B
      E -->|Oui| G[Merge vers la branche par défaut]
      G -->|Périodiquement| H[Branche déployée automatiquement]

      subgraph "Pipeline de déploiement"
          H --> I[Création de paquet]
          I --> K[Environnement canari]
          K --> L[Validation QA]
          L --> M[Environnement principal]

      end

Composition du pipeline de déploiement

Notre approche de déploiement utilise les capacités CI/CD natives de GitLab afin d'orchestrer des déploiements complexes sur une infrastructure hybride. Voici comment nous procédons.

Build

Le build de GitLab constitue en soi un sujet complexe, c'est pourquoi nous en aborderons les détails à un niveau général.

Nous construisons à la fois notre paquet Omnibus et nos images Cloud Native GitLab (CNG). Les paquets Omnibus se déploient sur notre flotte Gitaly (notre couche de stockage Git), tandis que les images CNG exécutent tous les autres composants sous forme de charges de travail conteneurisées. D'autres services dynamiques comme Postgres et Redis ont pris une telle ampleur que nous disposons d'équipes dédiées qui les gèrent séparément. Pour GitLab.com, ces systèmes ne sont pas déployés lors de nos procédures de déploiement automatique.

Nous disposons d'un pipeline planifié qui examine régulièrement gitlab-org/gitlab et recherche le commit le plus récent sur la branche par défaut avec un pipeline réussi (« vert »). Les pipelines verts signalent que chaque composant de GitLab a réussi sa suite de tests complète. Nous créons ensuite une branche déployée automatiquement à partir de ce commit.

Une séquence d'événements est déclenchée : nous devons construire ce paquet et tous les composants qui font partie de notre monolithe. Un autre pipeline planifié sélectionne le dernier paquet construit et initie le pipeline de déploiement, ce qui ressemble à ceci :

  graph LR
      A[Créer une branche] --> B[Build]
      B --> C[Choisir le paquet construit]
      C --> D[Démarrer le pipeline de déploiement]

Le build prend un certain temps et, étant donné que les déploiements peuvent varier en raison de diverses circonstances, nous choisissons le dernier build à déployer. Techniquement, nous construisons plus de versions de GitLab pour GitLab.com que nous n'en déploierons jamais. Cela nous permet de toujours disposer d'un paquet prêt à être utilisé, ce qui nous rapproche le plus possible d'un produit entièrement livré en continu pour GitLab.com.

Validation basée sur l'environnement et stratégie canari

L'assurance qualité (QA) ne constitue pas ici une simple réflexion après coup : elle est intégrée à chaque couche, du développement au déploiement. Notre processus QA exploite des suites de tests automatisées qui incluent des tests unitaires, des tests d'intégration et des tests de bout en bout qui simulent les interactions réelles des utilisateurs avec les fonctionnalités de GitLab. Mais plus important encore pour notre pipeline de déploiement, notre processus QA fonctionne en synergie avec notre stratégie canari via une validation basée sur l'environnement .

Dans le cadre de notre approche de validation, nous exploitons les déploiements canari natifs de GitLab. Ces derniers permettent une validation contrôlée des modifications avec une exposition limitée au trafic avant le déploiement complet en production. Environ 5 % de l'ensemble du trafic passe par l'étape canari. Cette approche augmente la complexité des migrations de base de données, mais des étapes canari réussies garantissent le déploiement d'un produit fiable de manière transparente.

Les fonctionnalités de déploiement canari que vous utilisez dans GitLab ont été affinées grâce à la gestion de l'un des scénarios de déploiement les plus complexes en production. Lorsque vous implémentez des déploiements canari pour vos applications, vous utilisez des modèles éprouvés à très grande échelle. Notre processus de déploiement suit une stratégie de déploiement progressif :

1. Préproduction canari : environnement de validation initial
2. Production canari : trafic de production limité
3. Préproduction environnement principal : déploiement complet de l'environnement de préproduction
4. Production environnement principal : déploiement complet en production

  graph TD
      C[Déploiement préproduction canari]
      C --> D[QA – smoke tests étape environnement principal]
      C --> E[QA – smoke tests étape canari]
      D --> F
      E --> F{Tests réussis ?}
      F -->|Oui| G[Déploiement production canari]
      G --> S[QA – smoke tests étape environnement principal]
      G --> T[QA – smoke tests étape canari]
      F -->|Non| H[Création de ticket]
      H --> K[Correction et rétroportage]
      K --> C

      S --> M[Surveillance trafic canari]
      T --> M[Période de stabilisation surveillance trafic canari]
      M --> U[Vérifications de sécurité production]
      U --> N[Préproduction environnement principal]
      N --> V[Production environnement principal]

Notre validation QA intervient à plusieurs points de contrôle tout au long de ce processus de déploiement progressif : après chaque déploiement canari, puis de nouveau après les migrations post-déploiement. Cette approche multi-couches garantit que chaque phase de notre stratégie de déploiement dispose de son propre filet de sécurité. Vous pouvez en apprendre davantage sur l'approche de test complète de GitLab dans notre handbook.

Pipeline de déploiement

Voici les défis que nous relevons avec notre pipeline de déploiement.

Considérations relatives à l'architecture technique

GitLab.com représente une complexité de déploiement réelle à grande échelle. En tant que plus grande instance GitLab connue, les déploiements utilisent notre chart Helm GitLab officiel et le paquet Linux officiel, soit les mêmes artefacts que nos clients utilisent. Vous pouvez en apprendre davantage sur l'architecture de GitLab.com dans notre manuel. Cette approche hybride signifie que notre pipeline de déploiement doit gérer intelligemment à la fois les services conteneurisés et les services Linux traditionnels au sein du même cycle de déploiement.

Utilisation de nos fonctionnalités à grande échelle (dogfooding) : nous déployons en utilisant les mêmes procédures que nous documentons pour les mises à niveau sans temps d’arrêt. Si certaines fonctionnalités ne fonctionnent pas correctement pour nous, nous ne les recommandons pas à nos clients. Cette contrainte que nous nous imposons stimule l'amélioration continue de nos outils de déploiement.

Les étapes suivantes sont exécutées pour toutes les mises à niveau d'environnement et d'étape :

  graph LR
      a[Préparation] --> c[Migrations régulières – étape canari uniquement]
      a --> f[Actifs – étape canari uniquement]
      c --> d[Gitaly]
      d --> k8s

      subgraph subGraph0["Charges de travail MV"]
        d["Gitaly"]
      end

      subgraph subGraph1["Charges de travail Kubernetes"]
        k8s["k8s"]
      end

      subgraph fleet["Flotte"]
        subGraph0
        subGraph1
      end

Détails des étapes :

• Préparation : cette étape valide la préparation du déploiement et effectue des vérifications de pré-déploiement.
• Migrations : cette étape exécute les migrations régulières de base de données, uniquement pendant l'étape canari. Étant donné que les étapes canari et environnement principal partagent la même base de données, ces modifications sont déjà disponibles lorsque l'étape environnement principal se déploie, ce qui signifie qu'il n'est plus nécessaire de répéter ces tâches.
• Actifs : nous exploitons un bucket GCS pour tous les actifs statiques. Si de nouveaux actifs sont créés, nous les importons vers notre bucket de sorte qu'ils soient immédiatement disponibles pour notre étape canari. Comme nous exploitons WebPack pour les actifs et utilisons correctement les SHA dans le nommage de nos actifs, nous pouvons être sûrs que nous n'écrasons pas un actif plus ancien. Par conséquent, les anciens actifs restent disponibles pour les déploiements plus anciens et les nouveaux actifs sont immédiatement disponibles lorsque l'étape canari commence son déploiement. Cela se produit uniquement pendant le déploiement de l'étape canari. Étant donné que l'étape canari et l'étape environnement principal partagent le même stockage d'actifs, ces modifications sont déjà disponibles lorsque l'étape environnement principal se déploie.
• Gitaly : cette étape met à jour la couche de stockage de la machine virtuelle Gitaly via notre paquet Linux Omnibus sur chaque nœud Gitaly. Ce service est unique car nous le regroupons avec git. Par conséquent, nous devons garantir que ce service soit capable de procéder à des mises à niveau atomiques. Nous exploitons un encapsuleur autour de Gitaly, qui nous permet d'installer une version plus récente de Gitaly et d'utiliser la bibliothèque tableflip afin de faire pivoter proprement le Gitaly en cours d'exécution, et de garantir la haute disponibilité de ce service sur chacune de nos instances.
• Kubernetes : déploie les composants GitLab conteneurisés via notre chart Helm. Notez que nous déployons sur de nombreux clusters répartis sur plusieurs zones pour des questions de redondance, ces étapes sont donc généralement divisées en leurs propres étapes afin de minimiser les dommages et de nous permettent d'arrêter un déploiement en cours si des problèmes critiques sont détectés.

Compatibilité multi-versions : le défi caché

À la lecture de nos processus, vous remarquerez qu'il existe une période pendant laquelle notre schéma de base de données est en avance sur le code que l'étape environnement principal connaît. Cette situation se produit parce que l'étape canari a déjà déployé le nouveau code et exécute des migrations régulières de base de données, mais l'étape environnement principal exécute toujours la version précédente du code qui ne connaît pas encore ces nouvelles modifications de base de données.

Exemple concret : imaginons que nous ajoutons un nouveau champ merge_readiness aux merge requests. Pendant le déploiement, certains serveurs exécutent du code qui s'attend à ce champ, tandis que d'autres ignorent son existence. Si nous gérons mal cette situation, GitLab.com sera inutilisable pour des millions d'utilisateurs. Si nous la gérons bien, personne ne remarquera quoi que ce soit.

Cette situation se produit également avec la plupart des autres services. Par exemple, si un client envoie plusieurs requêtes, il est possible que l'une d'entre elles aboutisse dans notre étape canari ; d'autres requêtes pourraient être dirigées vers l'étape environnement principal. Ce n'est pas très différent d'un déploiement, car il faut un temps considérable pour parcourir les quelques milliers de pods qui exécutent nos services.

À quelques exceptions près, la grande majorité de nos services exécutera une version légèrement plus récente de ce composant dans l'étape canari pendant une certaine période. Dans un sens, ces scénarios sont tous des états transitoires. Mais ils peuvent souvent persister pendant plusieurs heures ou jours dans un environnement de production actif. Par conséquent, nous devons les traiter avec le même soin que les états permanents. Pendant tout déploiement, plusieurs versions de GitLab s'exécutent simultanément, et elles doivent toutes cohabiter harmonieusement.

Opérations de base de données

Les migrations de base de données présentent un défi unique dans notre modèle de déploiement canari. Nous avons besoin de modifier le schéma afin de prendre en charge les nouvelles fonctionnalités et de maintenir notre capacité à effectuer un retour à la version précédente si des problèmes surviennent. Notre solution implique une séparation minutieuse des préoccupations :

• Migrations régulières : exécutées pendant l'étape canari, conçues pour être rétrocompatibles, constituées uniquement de modifications réversibles.
• Migrations post-déploiement : les migrations « point de non-retour » qui se produisent uniquement après plusieurs déploiements réussis.

Les modifications de base de données sont gérées avec précision et selon des procédures de validation approfondies :

  graph LR
      A[Migrations régulières] --> B[Déploiement étape canari]
      B --> C[Déploiement étape environnement principal]
      C --> D[Migrations post-déploiement]

Migrations post-déploiement

Les déploiements GitLab impliquent de nombreux composants. La mise à jour de GitLab n'est pas atomique, c'est pourquoi de nombreux composants doivent être rétrocompatibles.

Les migrations post-déploiement contiennent souvent des modifications qui ne peuvent pas être facilement annulées, comme les transformations de données, les suppressions de colonnes ou les modifications structurelles qui entraîneraient une rupture dans les versions de code plus anciennes. En les exécutant après plusieurs déploiements réussis, nous garantissons les aspects suivants :

1. Le nouveau code est stable et il est peu probable que nous ayons besoin de devoir retourner à la version précédente.
2. Les caractéristiques de performance sont bien comprises en production.
3. Tous les cas marginaux ont été découverts et traités.
4. Le rayon d'impact est minimisé en cas de problème.

Cette approche offre un équilibre optimal entre un déploiement rapide des fonctionnalités via les releases canari et des capacités de retour à la version précédente jusqu'à ce que nous ayons suffisamment confiance dans la stabilité du déploiement.

Modèle étendre-migrer-réduire : nos modifications de compatibilité de base de données, frontend et application suivent une approche en trois phases soigneusement orchestrée.

1. Étendre : ajouter de nouvelles structures (colonnes, index) tout en gardant les anciennes fonctionnelles.
2. Migrer : déployer le nouveau code d'application qui utilise les nouvelles structures.
3. Réduire : supprimer les anciennes structures dans les migrations post-déploiement une fois que tout est stable.

Exemple concret : lors de l'ajout d'une nouvelle colonne merge_readiness aux merge requests :

1. Étendre : ajouter la nouvelle colonne avec une valeur par défaut ; le code existant l'ignore.
2. Migrer : déployer le code qui lit et écrit dans la nouvelle colonne tout en prenant en charge l'ancienne approche.
3. Réduire : après plusieurs déploiements réussis, supprimer l'ancienne colonne dans une migration post-déploiement

Toutes les opérations de base de données, le code d'application, le code frontend et bien d'autres, sont soumis à un ensemble de directives que les équipes d’ingénieries doivent respecter, que vous pouvez consulter dans notre documentation sur la compatibilité multi-versions.

Résultats et impact

Notre infrastructure de déploiement offre des avantages mesurables :

Pour GitLab

• Jusqu'à 12 déploiements quotidiens sur GitLab.com
• Déploiements sans temps d’arrêt au service de millions de développeurs
• Application de correctifs de sécurité en production en quelques heures au lieu de plusieurs jours
• Nouvelles fonctionnalités validées en production à grande échelle avant la disponibilité générale

Pour nos clients

• Modèles de déploiement éprouvés que vous pouvez adopter pour vos propres applications
• Fonctionnalités testées en conditions réelles sur la plus grande instance GitLab au monde avant d'atteindre votre environnement
• Documentation qui reflète les pratiques de production réelles, et non des bonnes pratiques théoriques
• Fiabilité des procédures de mise à niveau recommandées par GitLab à toute échelle

Points clés pour les équipes d'ingénierie

Le pipeline de déploiement de GitLab représente un système sophistiqué qui met en jeu la vélocité de déploiement et la fiabilité opérationnelle. Le modèle de déploiement progressif, l'intégration complète des tests et les capacités robustes de retour à la version précédente fournissent une base pour une livraison logicielle fiable à grande échelle.

Les équipes d'ingénierie qui implémentent des systèmes similaires doivent avoir les points clés suivants en tête :

• Tests automatisés : couverture de tests complète tout au long du pipeline de déploiement
• Déploiement progressif : déploiements par étapes afin de minimiser les risques et permettre une récupération rapide
• Intégration de la surveillance : observabilité complète à travers toutes les étapes de déploiement
• Réponse aux incidents : capacités de détection et de résolution rapides pour les problèmes de déploiement

L'architecture de GitLab démontre comment des systèmes CI/CD modernes peuvent gérer la complexité de déploiements à grande échelle tout en maintenant la vélocité requise pour un développement logiciel compétitif.

Note importante sur la portée

Cet article couvre spécifiquement le pipeline de déploiement pour les services qui font partie du paquet GitLab Omnibus et du chart Helm, soit le monolithe GitLab principal et ses composants étroitement intégrés.

Cependant, le paysage d'infrastructure de GitLab s'étend au-delà de ce qui est décrit ici. D'autres services, notamment nos services d'IA et les services qui pourraient faire partie d'une étude de faisabilité, suivent une approche de déploiement différente au moyen de notre plateforme interne Runway.

Si vous travaillez avec ces services ou souhaitez en savoir plus, vous pouvez obtenir plus d'informations dans notre documentation dédiée à Runway.

D'autres offres, telles que GitLab Dedicated, sont déployées de manière plus alignée avec ce que nous attendons que les clients soient capables de réaliser eux-mêmes au moyen de GitLab Environment Toolkit. Si vous souhaitez en savoir plus, consultez le projet GitLab Environment Toolkit.

Les stratégies de déploiement, les considérations architecturales et les complexités de pipeline décrites dans cet article représentent l'approche éprouvée que nous utilisons pour notre plateforme principale, mais comme toute grande organisation d'ingénierie, nous disposons de plusieurs stratégies de déploiement adaptées aux différents types de services et niveaux de maturité.

Pour plus de documentation sur le déploiement automatique et nos procédures, vous pouvez consulter les liens ci-dessous :

• Déploiements d'ingénierie
• Documentation sur les procédures de release