Découvrez comment The Zebra a renforcé la sécurité de ses pipelines
Vous souhaitez découvrir ce que GitLab Ultimate peut offrir à votre équipe ?
The Zebra a adopté GitLab pour remplacer GitHub et Jenkins pour la gestion du code source, les processus CI/CD et la sécurité.
Site de comparaison d'assurances en ligne, The Zebra a adopté GitLab pour la gestion de son code source (SCM), ainsi que pour les processus CI/CD et les tests SAST et DAST.
L'assurance en noir et blanc
Comparateur en ligne créé en 2012 pour offrir un moyen simplifié de comparer les fournisseurs d'assurance, The Zebra analyse les options d'assurance automobile et propose à ses clients les meilleurs tarifs disponibles. The Zebra s'est récemment étendu à l'assurance habitation et à l'assurance locataire.
Trop de plug-ins sans aucun avantage
Auparavant, The Zebra utilisait GitHub en tant que dépôt et Jenkins pour les déploiements. Terraform était également utilisé pour le déploiement sur AWS. Le nombre de plug-ins Jenkins engendrait cependant une quantité écrasante de travail de gestion. Leur diversité entraînait par ailleurs des failles de sécurité. Certains outils n'étaient en effet plus pris en charge ou trop fragiles pour être mis à jour dans l'environnement de déploiement.
« Notre plus gros problème était d'utiliser Jenkins pour effectuer nos déploiements avant GitLab. Nous y avons intégré beaucoup de plug-ins. Le système était si fragile que personne ne voulait y toucher », explique Dan Bereczki, Sr. Software Manager. « Quiconque essayait d'y toucher l'endommageait. Résultat ? Des déploiements interrompus pendant une demi-journée, voire une journée, afin d'apporter des corrections ou des mises à niveau ».
Les équipes souhaitaient améliorer le processus CI/CD existant, mais cela impliquait d'ajouter d'autres plug-ins à Jenkins et donc de compliquer davantage le niveau de maintenance existant. The Zebra avait besoin d'une nouvelle solution qui intégrerait les tests et la sécurité, et qui permettrait des déploiements sur une variété de plateformes différentes.
Une migration rapide sans aucun plug-ins
L'équipe de The Zebra a alors exploré différentes plateformes afin de remplacer les plug-ins existants et de réduire le stress lié à leur gestion. Son choix s'est porté sur GitLab en raison de son dépôt amélioré, comprenant déjà toutes les fonctionnalités nécessaires intégrées de base, sans devoir gérer des plug-ins supplémentaires. Et l'argument de vente qui a fait pencher la balance en faveur de GitLab ? Ses fonctionnalités CI/CD.
De plus, les équipes étaient impatientes d'adopter GitLab en raison de ses fonctionnalités que d'autres solutions ne proposent pas, comme la sécurité intégrée. « En plus de mieux contrôler leurs processus, les équipes ont pu constater la simplicité de la transition. Nous avons réalisé la migration en moins de trois mois », déclare Dan Bereczki. 95 % du code de Jenkins a ainsi été migré pendant cette période. Depuis lors, l'entreprise a complètement abandonné Jenkins et GitHub.
Les six équipes de développement d'applications, ainsi que quelques autres équipes en dehors du développement, utilisent désormais GitLab. « Aujourd'hui, au lieu d'avoir une ou deux personnes qui comprennent les subtilités de Jenkins et peuvent résoudre les problèmes, tout le monde sait comment développer avec des pipelines GitLab », affirme Dan Bereczki. Les équipes sont passées de l'utilisation de 3 outils, GitHub, Codeship CI et Jenkins Deploy, à l'utilisation de la solution entièrement intégrée et automatisée GitLab CI/CD.
Une plateforme, plusieurs solutions
Avec GitLab, The Zebra peut désormais se concentrer sur le déploiement continu. Les équipes peuvent en effet déployer à leur rythme, de manière autonome, sans contrainte d'autres calendriers. Chaque équipe de développement joue désormais un rôle plus actif dans le processus de déploiement, car elles maîtrisent le fonctionnement du pipeline CI et peuvent y contribuer directement. En outre, l'infrastructure ne constitue plus un obstacle au déploiement.
Le workflow commence généralement par une demande émanant du marketing, qui se transforme en un dossier technique divisé ensuite en une série de tickets JIRA, puis assigné à l'équipe appropriée. Une fois que le travail commence, le code est généré et stocké dans le dépôt GitLab. L'équipe utilise ensuite le pipeline CI/CD de GitLab pour le déployer dans l'environnement de développement. L'infrastructure en tant que code (IaC) est gérée via Terraform, ce qui garantit que les changements de configuration sont maintenus tout au long du processus de test et de déploiement.
Les équipes s'appuient sur Amazon EKS avec RDS. Le routage du trafic est d'abord géré par Cloudflare, puis par Elastic Load Balancing en interne. Lorsque les développeurs doivent connecter les services de The Zebra à des services tiers externes, ils utilisent Amazon Virtual Private Cloud. « Nous ne voulons pas de systèmes qui soient des boîtes noires dont personne ne connaît le fonctionnement. Nous souhaitons en finir avec ça », explique Dan Bereczki.
GitLab a permis d'établir des relations interfonctionnelles entre les équipes de développement, lesquelles étant désormais propriétaires de leur propre code jusqu'à la production. Les développeurs comprennent chaque étape du déploiement : ils peuvent résoudre les problèmes et apporter des modifications sans craindre de perturber d'autres parties du workflow.
Les fonctionnalités SAST et DAST de GitLab facilitent la mise en conformité avec la certification SOC2 Type 1. Les équipes sont aujourd'hui en cours de certification SOC2 Type 2. Des tests supplémentaires et des mesures de sécurité ont également été mis en place afin de réduire les risques. « Plus important encore, nous avons pu identifier toute une série de failles dont nous ne soupçonnions même pas l'existence. Nous nous employons à les corriger au plus vite », poursuit Dan Bereczki. Jusqu'à présent, celles identifiées comme critiques et prioritaires ont été éliminées de quatre projets. « Le point positif ? Comme cela fait maintenant partie intégrante du pipeline, nous n'aurons plus à rattraper le temps perdu lorsque nous programmerons un test de pénétration ou lorsque nous effectuerons des tests trimestriels ou semestriels », ajoute Dan Bereczki.
À la date de publication, toutes les informations et les personnes mentionnées dans l'étude de cas sont exactes.