Cet article a été traduit. Retrouvez la version originale sur notre blog anglais.
Note de la rédaction : nous invitons parfois les membres de notre communauté de clients à contribuer au blog de GitLab. Nous remercions aujourd'hui Carl Myers, responsable des plateformes CI chez Indeed, de nous avoir fait part de son expérience avec GitLab.
Chez Indeed, notre mission est d'aider chacun à trouver un emploi. Indeed est le plus grand site d'offres d'emploi au monde, accueillant plus de 350 millions de visiteurs uniques chaque mois.
Du côté des équipes de plateforme d'ingénierie d'Indeed, la devise est légèrement différente : « Nous aidons ceux qui aident chacun à trouver un emploi ». Depuis près de vingt ans, les chercheurs d'emploi sont au cœur de notre culture d'ingénierie fondée sur les données. Dans ce contexte, notre responsabilité est de créer des outils qui non seulement facilitent cet objectif, mais qui permettent également aux ingénieurs d'offrir chaque jour des opportunités aux candidats.
L'intégration continue de GitLab a permis à l'équipe de plateforme CI d'Indeed, composée de seulement 11 personnes, d'accompagner efficacement des milliers d'utilisateurs dans toute l'entreprise. Indeed a également constaté d'autres avantages, avec notamment :
- une augmentation des pipelines quotidiens de 79 %
- une réduction de 10 à 20 % des coûts de matériel de CI
- une diminution des demandes d'assistance
L'évolution de notre plateforme CI : de Jenkins vers une solution évolutive
Comme de nombreuses grandes entreprises dans le domaine technologique, nous avons construit notre plateforme CI de manière organique, au fil de l'évolution de l'entreprise, en faisant appel aux solutions open source et standard qui étaient disponibles à l’époque. En 2007, lorsque Indeed comptait moins de 20 ingénieurs, nous utilisions Hudson, le prédécesseur direct de Jenkins.
Une vingtaine d'années plus tard, nous employons aujourd'hui des milliers d'ingénieurs. Nous avons progressivement amélioré nos outils au fil de l'arrivée de nouvelles technologies, notamment en passant à Jenkins vers 2011. Une autre avancée nous a permis de déplacer la plupart de nos charges de travail vers des nœuds de travail cloud dynamiques grâce à AWS EC2. Il est toutefois devenu évident que l'architecture de notre système avait atteint ses limites lorsque nous sommes entrés dans l'ère de Kubernetes.
L'architecture de Jenkins n'est en effet pas conçue pour le cloud. Le fonctionnement de Jenkins repose sur un nœud « contrôleur », un point de défaillance unique qui exécute les parties critiques d'un pipeline et décharge certaines étapes vers les nœuds de travail (qui peuvent évoluer horizontalement dans une certaine mesure). Les contrôleurs constituent également un axe de mise à l'échelle manuelle.
Si vos tâches sont trop nombreuses pour un contrôleur donné, elles doivent être partitionnées manuellement entre plusieurs contrôleurs. CloudBees propose des solutions pour contourner ce problème, notamment avec le CloudBees Jenkins Operations Center qui vous permet de gérer votre constellation de contrôleurs depuis un seul endroit centralisé. Cependant, les contrôleurs restent difficiles à exécuter dans un environnement Kubernetes, car chaque contrôleur est un point de défaillance unique et fragile. Des activités telles que les déploiements de nœuds ou des défaillances matérielles peuvent ainsi entraîner des temps d'arrêt.
Au-delà des limitations techniques inhérentes à Jenkins, notre plateforme CI a également rencontré des problèmes dont nous étions malheureusement à l'origine. Par exemple, nous avons utilisé le DSL Groovy de Jenkins pour générer des jobs à partir du code contenu dans chaque dépôt. Chaque projet s'est ainsi retrouvé avec un pipeline individuel de jobs copiés, ce qui a engendré des centaines de versions difficiles à maintenir et à mettre à jour. Bien que la culture d'ingénierie d'Indeed encourage la flexibilité et permette aux équipes de travailler dans des dépôts distincts, cette flexibilité était devenue un fardeau, car les équipes consacraient trop de temps à répondre aux demandes de maintenance régulières.
Ayant pris conscience de cette dette technique, nous nous sommes tournés vers le modèle « Golden Path », qui permet une certaine flexibilité tout en offrant une méthode par défaut pour simplifier les mises à jour et encourager des pratiques cohérentes dans tous les projets.
L'équipe de plateforme CI d'Indeed est relativement petite. Nous comptons environ 11 ingénieurs qui gèrent des milliers d'utilisateurs, répondent aux demandes d'assistance, effectuent des mises à niveau et des opérations de maintenance, et offrent une assistance constante à notre entreprise mondiale.
Comme notre équipe prend en charge non seulement notre instance GitLab, mais également l'ensemble de la plateforme CI, y compris le serveur d'artefacts, notre code de compilation partagé et de multiples autres composants personnalisés de notre plateforme, nous avions énormément de travail. Nous avions besoin d'une solution qui nous aiderait à résoudre nos problèmes tout en exploitant au maximum nos ressources existantes.
Notre migration vers GitLab CI
Après un examen minutieux de sa conception avec les principales parties prenantes, nous avons décidé de migrer l'ensemble de l'entreprise de Jenkins vers le système d'intégration continue de GitLab.
Nos principales raisons étaient les suivantes :
- Nous utilisions déjà GitLab pour la gestion du code source.
- GitLab est une offre complète qui fournit tout ce dont nous avons besoin pour l'intégration continue.
- GitLab CI est conçu pour l'évolutivité et le cloud.
- GitLab CI nous permet de générer des modèles qui élargissent d'autres modèles, ce qui est compatible avec notre stratégie « Golden Path ».
- GitLab est un logiciel open source et l'équipe de GitLab nous a toujours aidés à soumettre des correctifs, ce qui nous offre davantage de flexibilité et renforce notre confiance.
Au moment de notre annonce officielle de la disponibilité de la plateforme CI de GitLab pour tous les utilisateurs, 23 % de l'ensemble des compilations étaient déjà effectuées dans le système d'intégration continue de GitLab.
Notre plus grand défi lors de cette migration était que « le diable se niche dans les détails ». Du fait du nombre de compilations personnalisées présentes dans Jenkins, nous savions qu'un outil de migration automatisé ne fonctionnerait pas pour la majorité des équipes. Or, la plupart des avantages du nouveau système ne seraient concrétisés qu'une fois l'ancien système complètement abandonné. Ce n'est qu'alors que nous pourrions cesser d'utiliser le matériel et économiser les frais de licence CloudBees.
La parité des fonctionnalités et les avantages de repartir à zéro
Indeed utilise de nombreuses technologies différentes, mais les trois langages les plus courants sont Java, Python et JavaScript. Ces piles technologiques de langages sont utilisées pour créer des bibliothèques, des déployables (services Web ou applications) et des tâches cron (un processus qui s'exécute à intervalles réguliers, par exemple pour créer un ensemble de données dans notre lac de données). Chacune de ces piles correspondait à un type de projet spécifique (par ex. Java Library, Python Cronjob, JavaScript Webapp, etc.) avec une configuration de base dans Jenkins. Par conséquent, nous avons dû générer un modèle « Golden Path » dans le système d'intégration continue de GitLab pour chacun de ces types de projets.
La plupart des utilisateurs pouvaient utiliser ces modèles recommandés tels quels. Pour ceux qui avaient besoin de les personnaliser, le « Golden Path » constituait un point de départ utile leur permettant de modifier uniquement les aspects nécessaires, tout en bénéficiant de mises à jour de modèles centralisées à l'avenir.
Nous avons rapidement constaté que la plupart des utilisateurs, même ceux qui avaient besoin de personnaliser certains aspects de leur projet, étaient tout à fait disposés à adopter ce modèle et à l'essayer. S'ils s'apercevaient que certaines de leurs personnalisations n'étaient pas incluses dans le modèle, ils savaient qu'ils pouvaient toujours les ajouter ultérieurement. C'était un résultat surprenant ! Nous pensions en effet que les équipes qui avaient investi dans des personnalisations importantes seraient réticentes à l'idée de les abandonner. Or, dans la majorité des cas, les équipes ne s'en souciaient tout simplement plus. Cela nous a permis de migrer de nombreux projets très rapidement : il suffisait en effet de déposer notre « Golden Path » (un petit fichier d'environ 6 lignes avec des inclusions) dans leur projet pour que chaque équipe puisse s'occuper du reste.
L'innersource à la rescousse
L'équipe de plateforme CI a également adopté une politique de « priorité aux contributions externes » pour encourager la participation de tous les membres de l'entreprise. C'est ce qu'on appelle parfois l'innersource. Nous avons créé des tests et une documentation pour encourager les contributions externes (c'est-à-dire externes à notre équipe immédiate). Les équipes qui souhaitaient créer des personnalisations pouvaient ainsi les ajouter au « Golden Path » tout en les activant ou désactivant à l'aide d'un feature flag. Cette approche a encouragé une meilleure collaboration et un plus grand respect des personnalisations (parce que celles-ci faisaient désormais partie du code base commun).
Autre avantage : les équipes qui attendaient désespérément une fonctionnalité dont elles avaient besoin pouvaient désormais la créer elles-mêmes. Nous pouvons désormais leur donner le choix : « Oui, nous prévoyons de mettre en œuvre cette fonctionnalité dans quelques semaines, mais si vous en avez besoin plus tôt, nous serions ravis d'accepter une contribution ». Au final, de nombreuses fonctionnalités de base nécessaires à la parité ont été développées de cette manière, plus rapidement et mieux que nos ressources ne le permettaient. La migration n'aurait pas été un succès sans ce modèle.
En avance sur le calendrier et en dessous du budget
Notre licence CloudBees arrivait à expiration le 1er avril 2024. Nous avons donc fixé cette date comme date d'achèvement de la migration. Cette échéance était particulièrement ambitieuse, car, à l'époque, 80 % de l'ensemble des compilations (soit 60 % de tous les projets) utilisaient encore Jenkins pour le processus d'intégration continue. Plus de 2 000 fichiers Jenkins (Jenkinsfiles) devaient donc encore être recréés ou remplacés par nos modèles « Golden Path ».
Pour atteindre cet objectif, nous avons mis à disposition des équipes une documentation et des exemples, ajouté des fonctionnalités dans la mesure du possible et aidé nos utilisateurs à offrir des contributions quand ils le pouvaient.
Nous avons mis en place des permanences régulières, durant lesquelles tous les utilisateurs pouvaient nous poser des questions ou demander notre aide pour migrer. Nous avons également donné la priorité aux questions d'assistance relatives à la migration. Certains membres de notre équipe sont devenus des experts du système d'intégration continue de GitLab et ont partagé leur expertise avec le reste de l'équipe et toute l'entreprise.
La migration automatique n'était pas adaptée à la plupart des projets, mais nous avons découvert qu'elle pouvait fonctionner pour un petit sous-ensemble de projets où les personnalisations étaient rares. Nous avons créé une campagne de changement par lots Sourcegraph afin de soumettre des merge requests pour migrer des centaines de projets et, avons convaincu les utilisateurs à accepter ces merge requests.
Nous avons également partagé des exemples de réussite notables avec toutes les équipes. Comme les utilisateurs ajoutaient de nouvelles fonctionnalités à nos modèles « Golden Path », nous avons annoncé que ces fonctionnalités seraient ajoutées « gratuitement » lors de la migration vers GitLab CI. Ces fonctionnalités comportaient entre autres un scan de sécurité et de conformité intégré, des notifications Slack pour les compilations CI et des intégrations avec d'autres systèmes internes.
Nous avons également mené une campagne de tests agressifs. Dans ce cadre, nous avons automatiquement désactivé les jobs Jenkins qui n'avaient pas été exécutés ou qui n'avaient pas abouti depuis un certain temps, en disant aux utilisateurs que s'ils en avaient besoin, ils pouvaient les réactiver. C'est un moyen simple d'identifier les jobs qui sont réellement nécessaires. Nous avons ainsi identifié des milliers de jobs qui n'avaient pas été exécutés une seule fois depuis notre dernière migration CI (de Jenkins vers Jenkins). Nous en avons déduit que nous pouvions ignorer la vaste majorité de ces jobs sans aucun risque.
En janvier 2024, nous avons annoncé que tous les contrôleurs Jenkins passeraient en lecture seule (sans compilation) à moins qu'une exception ne soit explicitement demandée par les utilisateurs. La propriété des contrôleurs était mieux connue et ils s'alignaient généralement sur la structure de notre entreprise. Il était donc logique de se concentrer sur les contrôleurs plutôt que sur les jobs. De plus, la liste des contrôleurs était beaucoup plus gérable que celle des jobs.
Pour obtenir une exception, les utilisateurs devaient identifier leurs contrôleurs dans une feuille de calcul, puis saisir leurs coordonnées à côté de chacun d'eux. Nous avons ainsi pu obtenir une liste à jour et fiable des parties prenantes avec lesquelles nous pouvions effectuer un suivi à mesure que la migration progressait, mais cela a également permis aux utilisateurs d'indiquer clairement les jobs dont ils avaient absolument besoin. Nous sommes passés d'environ 400 contrôleurs à 220 au mois de janvier, mais seuls 54 contrôleurs ont nécessité des exceptions (et parmi ces contrôleurs, plusieurs appartenaient à notre équipe pour exécuter nos tests et déploiements canari)).
Nous avions donc une liste gérable d'environ 50 équipes et chaque membre de notre équipe a été chargé d'en contacter un certain nombre pour évaluer leurs progrès dans le cadre de la migration. Nous avons consacré les mois de janvier et février à cette tâche et découvert que certaines équipes prévoyaient de terminer leur migration sans notre aide avant le 28 février. D'autres prévoyaient de mettre fin à leurs projets existants avant cette date, et seule une petite minorité pensait rencontrer des difficultés.
Nous avons pu travailler avec ce petit groupe d'équipes pour leur offrir un niveau d'accompagnement très personnalisé. Nous leur avons expliqué que nous ne disposions pas de l'expertise nécessaire pour effectuer la migration à leur place, mais que nous pouvions collaborer avec un expert métier de leur équipe. Dans certains cas, nous avons écrit le code et l'équipe s'est chargée de la revue de code, ou vice-versa. Au final, tout notre travail a porté ses fruits et nous avons pu désactiver Jenkins à la date que nous avions annoncée 8 mois plus tôt.
Résultats : une intégration continue plus efficace et des utilisateurs plus satisfaits
À son apogée, notre plateforme CI Jenkins permettait d'exécuter plus de 14 000 pipelines par jour et de réaliser des milliers de projets. Aujourd'hui, notre plateforme CI GitLab exécute régulièrement plus de 25 000 pipelines par jour, mais peut en traiter plus de 40 000 en une seule journée. Le coût différentiel de chaque job dans chaque pipeline est similaire à celui de Jenkins, mais sans les coûts indirects du matériel nécessaire au fonctionnement des contrôleurs. De plus, ces contrôleurs agissaient comme des points de défaillance uniques et des limiteurs de mise à l'échelle, ce qui nous obligeait à diviser artificiellement notre plateforme en segments. Bien qu'une comparaison directe soit difficile, nous constatons que l'élimination de ces frais généraux permet de réduire nos coûts de matériel d'intégration continue de 10 à 20 %. En outre, la charge d'assistance de GitLab CI est bien moindre, car l'application évolue automatiquement dans le cloud et offre une résilience interzone, et le langage utilisé pour la génération de modèles s'accompagne d'une excellente documentation publique.
Un avantage tout aussi important, sinon plus, est que nous sommes maintenant à plus de 70 % d'adoption de nos modèles « Golden Path ». Cela signifie que lorsque nous déployons une amélioration, plus de 5 000 projets en bénéficient immédiatement sans qu'aucune action ne soit requise de la part des équipes d'Indeed. Nous avons ainsi pu déplacer certains jobs vers des instances ARM64 plus rentables, mettre à jour plus facilement les images de compilation des utilisateurs et mieux gérer d'autres opportunités de réduction des coûts. Et le résultat dont nous sommes le plus fiers ? Nos utilisateurs sont plus satisfaits grâce à la nouvelle plateforme.
À propos de l'auteur : Carl Myers vit à Sacramento, en Californie, et est le responsable de l'équipe de plateforme CI d'Indeed. Depuis près de vingt ans, Carl crée des outils internes et des plateformes de développement pour le bonheur d'ingénieurs d'entreprises de toutes tailles.
Remerciements : Cette migration n'aurait pas été possible sans le travail inlassable de Tron Nedelea, Eddie Huang, Vivek Nynaru, Carlos Gonzalez, Lane Van Elderen et de toute l'équipe de plateforme CI. L'équipe souhaite également remercier Deepak Bitragunta et Irina Tyree, dont le leadership a permis de garantir les ressources, l'adhésion et la cohérence à l'échelle de l'entreprise qui étaient nécessaires tout au long de ce long projet. Enfin, nous remercions tous les membres d'Indeed qui ont contribué au code, aux retours d'expérience, aux rapports de bogues et à la migration des projets.
Ce texte est une version modifiée de l'article « How Indeed Replaced Its CI Platform with Gitlab CI », publié à l'origine sur le blog dédié à l'ingénierie d'Indeed.
