Concilier coût et continuité
La plateforme devait absorber les variations de charge des jobs CI/CD sans dimensionner l’instance GitLab centrale pour leurs pics. Les livraisons devaient rester compatibles avec les opérations de maintenance.
Moderniser une plateforme GitLab et maîtriser ses coûts d’exploitation
Maîtriser les dépenses de plateforme sans déplacer les risques vers la maintenance, les sauvegardes et la capacité CI/CD.
Pour une plateforme utilisée par plusieurs équipes, le fondateur a conçu le passage de GitLab.com à GitLab self-managed sur GCP, avec des runners GKE. Les dépenses de plateforme GitLab concernées ont baissé d’environ 90 %, hors coût complet d’exploitation.
Organisation à équipes techniques · Plateforme GitLab et exécution CI/CD · Rôle de l’intervenant : Architecte Cloud et DevOps senior
≈−90 %
des dépenses de plateforme GitLab concernées, hors coût complet GCP/CI/CD
Étude sans nom client issue du parcours du fondateur d’AKITA Consulting, non présentée comme un contrat direct de la société. Les résultats concernent le périmètre décrit et ne garantissent aucun résultat futur.
Réalisations
Le défi
GitLab servait à la livraison de plusieurs équipes. Le fondateur intervenait sur la conception Cloud et DevOps d’un nouvel hébergement, alors que les besoins de CI/CD et les dépenses de plateforme évoluaient. Passer de GitLab.com à une instance gérée en interne transférait à l’équipe sauvegardes, mises à jour, accès administratifs et réponse aux incidents. La comparaison ne pouvait donc pas se limiter au prix du service hébergé.
Sécuriser une plateforme désormais opérée
L’hébergement self-managed exigeait des ressources GCP privées, une administration contrôlée, des sauvegardes séparées et une trajectoire de reprise. La réduction des dépenses ne devait pas masquer ces responsabilités nouvelles.
La solution
Concevoir la migration GitLab
Concevoir le passage de GitLab.com à GitLab self-managed sur des machines GCP privées. Isoler les accès réseau et réserver l’administration aux personnes autorisées, plutôt que d’exposer la plateforme et ses services internes.
Prévoir résilience et protection
Prévoir des sauvegardes distinctes de l’instance, une protection WAF et une procédure de reprise à tester. Intégrer dès la conception les mises à jour et la surveillance, désormais prises en charge par l’équipe opératrice.
Faire évoluer les runners
Séparer l’exécution des jobs GitLab CI/CD de l’instance centrale : des runners sur GKE, déployés avec Helm, ajustent leur capacité aux demandes. Cette isolation évite que les pics de jobs dictent la taille du serveur GitLab.
Valider les montées de version
Valider les nouvelles versions de GitLab et des runners dans un environnement de staging éphémère avant promotion. Vérifier les chemins de livraison et les contraintes de réseau avant une mise à jour de production.
Les résultats
Environ 90 % de baisse des dépenses GitLab concernées
Une baisse d’environ 90 % des dépenses de plateforme GitLab concernées a été rapportée. Le pourcentage ne mesure ni le coût complet d’exploitation de l’instance self-managed, ni la facture GCP ou CI/CD globale.
Un processus de maintenance vérifiable
Les runners GKE autoscalés isolent la capacité des jobs ; le staging éphémère fournit un parcours de validation avant les montées de version. Les sauvegardes et la reprise demeurent des tâches explicites de la plateforme opérée.
Les enseignements
Le self-managed est un échange de responsabilités
L’autohébergement échange une dépense de service contre des responsabilités d’exploitation : correctifs, surveillance, accès, sauvegardes et reprise. Une baisse de dépenses de plateforme ne suffit pas à conclure à une baisse équivalente du coût complet.
Les runners méritent un modèle séparé
Adapter la capacité des runners aux jobs évite de dimensionner l’instance GitLab pour leurs pics. Tester les versions en staging éphémère aide à traiter séparément les évolutions du serveur et des exécutants CI/CD.
AKITA / CONTACT
Votre plateforme CI/CD pèse sur les coûts ou la fiabilité ?
Évaluons ses flux, ses runners et ses obligations d’exploitation avant de décider d’une modernisation.
Échanger sur votre défi