Domaine : Livraison de produits d'épicerie

Produits JetBrains utilisés : TeamCity

Taille de l'organisation : 10,000

Pays : Pays-Bas

Picnic

Picnic est une appli de livraison de produits d’épicerie crée aux Pays-Bas en 2015. Grâce à sa technologie de pointe et au talent de son équipe, Picnic fait partie des entreprises technologiques européennes qui affichent la croissance la plus rapide.

« Nous étions à la recherche d'une solution gérée pour tous nos cas d'utilisation de CI. Nous avions également besoin d'agents autohébergés pour contrôler les logiciels que nous exécutons et les outils précis utilisés. TeamCity Cloud, combiné à des agents autohébergés, a fourni une solution sur mesure. Notre équipe de plus de 300 ingénieurs l'utilise avec plaisir et elle booste notre productivité. »

— Ivan Babiankou, ingénieur logiciel en chef chez Picnic

Informations sur l'entreprise

Veuillez vous présenter, en indiquant votre nom et votre fonction.

Je m'appelle Ivan Babiankou, je suis ingénieur logiciel en chef chez Picnic. Je fais partie de l'équipe Java Platform. J'ai participé au choix du successeur de notre précédente solution de CI et à la mise en œuvre de la migration.

Que fait votre entreprise ? Quelles sont ses offres principales ?

Picnic révolutionne la façon dont les gens font leurs courses. Parti d'une unique ville néerlandaise, Picnic dessert aujourd'hui plus de 200 villes dans trois pays : l'Allemagne, la France et les Pays-Bas. Sans magasins physiques, Picnic s'appuie exclusivement sur son application pour rendre les courses simples et rapides pour des millions d'utilisateurs.

Véhicule électrique emblématique de Picnic
Livraison dans des véhicules électriques emblématiques

En plus de l'application mobile destinée aux utilisateurs, nous créons la majorité des autres systèmes essentiels à l'entreprise, notamment une solution interne pour la gestion de l'entrepôt. Nous développons également tous les outils permettant de planifier les itinéraires des chauffeurs, de les aider à conduire en toute sécurité, d'optimiser les itinéraires de récupération des commandes dans l'entrepôt, etc.

Picnic emploie actuellement plus de 300 développeurs. La pile technologique de l'entreprise comprend entre autres GitHub, Java, Python, Swift, Kotlin, TypeScript, Angular, React, Android, iOS, MongoDB et Spring Boot.


Les défis précédant l'adoption de TeamCity

Quels produits de CI/CD utilisiez-vous auparavant et qu'est-ce qui vous a amenés à en chercher un nouveau ?

Nous avons commencé à nous intéresser à JetBrains TeamCity à la fin de l'année 2021, car nous étions en train de déborder du cadre de notre solution CI précédente. Deux points majeurs nous posaient problème : la lenteur des builds et la longueur de leurs files d'attente. Aux heures de pointe, certaines builds restaient en file d'attente pendant une heure avant de s'exécuter.

Dans notre ancienne solution, la principale approche pour remédier à cette situation consistait à augmenter drastiquement le nombre et la taille des agents de build, pour réduire ainsi le temps de build total. Mais cette solution n'était pas évolutive. Elle ne répondait pas au problème central de la vitesse de build. Nous avons donc décidé de chercher une nouvelle solution, plus efficace et plus rapide.

Pour remplacer notre solution de CI, nous avons cherché un système qui prendrait en charge l'ensemble de notre pile technologique et nous aiderait à normaliser les builds et les tests de nos applications. Nous utilisons Java et Python pour le développement des applications backend, GitHub comme VCS, ainsi que Kotlin, Swift et React Native pour le développement mobile.

Quelles autres solutions avez-vous envisagées ? Quels étaient vos principaux critères pour un outil de CI/CD ?

Nous avons commencé avec une longue liste de 10 fournisseurs de solutions et l'avons réduite à 3 : CircleCI, TeamCity et GitHub Actions. Notre principal objectif était de minimiser les temps d'attente et d'améliorer les performances de CI en réduisant le temps de build.

Une autre de nos exigences concernait les agents autohébergés. Au cours de l'analyse, nous avons réalisé que notre ancienne solution ne permettait pas de mettre rapidement à niveau les outils sur les agents. Chaque build impliquait 2 à 5 minutes d'installation des outils. Sachant que le temps moyen d'une build dure environ 9 minutes, cela n'a aucun sens de passer 3 minutes de plus à installer les outils au préalable. C'est ainsi que nous sommes arrivés à l'idée d'agents autohébergés dans lesquels nous disposerions des derniers outils, des performances appropriées et d'à peu près tout le nécessaire pour lancer nos builds directement.

La solution de CI devait se trouver dans le cloud. C'était un autre critère indispensable à nos yeux. Chez Picnic, nous essayons de gérer le moins de systèmes possible. Avec la CI, nous voulions disposer d'une solution gérée dont nous n'aurions pas à nous préoccuper. En même temps, des agents autohébergés dans le cloud nous permettent de déterminer précisément les logiciels et les outils que nous utilisons. Nous pouvons donc contrôler l'ensemble de l'environnement de build (le matériel utilisé et les outils exacts qui sont préinstallés) sans avoir à gérer le serveur de CI.


Statistiques quantitatives et de CI/CD

Nous comptons environ 300 utilisateurs de la CI, dont la plupart sont actifs et envoient des commits de manière assez intensive sur près de 200 projets. Ces projets suivent une structure assez hiérarchique dans TeamCity, avec plus de 120 racines VCS.

Nous disposons en outre de 40 agents de build pour un maximum de 40 builds simultanées. Nous exécutons près de 1 100 builds quotidiennement. Le temps total de build par jour avoisine les 10 000 minutes. Les agents ont besoin d'environ 2 minutes pour démarrer, et les builds sont rarement mises en file d'attente plus longtemps que cela.

Sur un mois, tout cela représente près de 300 000 minutes de temps de build.


Quelle partie de votre processus de développement est prise en charge par TeamCity ?

Nous utilisons TeamCity pour tout le développement interne. Une fois que vous avez ouvert une requête d'extraction dans GitHub, la CI le génère, exécute des tests unitaires, d'intégration et de composants, et vous envoie un bilan. Ça s'arrête à peu près là. Nous utilisons TeamCity jusqu'au moment où il produit un artefact de build, qui est ensuite poussé vers un dépôt pour un déploiement ultérieur.


Vers quoi, comment et où déployez-vous ?

Tous les agents de build Linux et ordinaires sont exécutés dans notre fournisseur cloud, AWS. Pour les applications iOS, nous disposons de quelques Mac minis qui sont reliés au réseau de notre bureau et connectés à TeamCity. En fait, l'équipe iOS utilisait déjà TeamCity sur site avant de migrer vers TeamCity Cloud.

Nous utilisons des agents avec des instances à la demande. Les instances ponctuelles restent une option très intéressante à l'horizon des améliorations futures.

Nous préparons nos propres images et utilisons TeamCity Cloud Profiles pour exécuter des agents autohébergés. Il s'agit, en fait, de machines EC2 dans AWS. Nous utilisons TeamCity et Packer pour créer les images AWS des agents.

Nous utilisons ensuite ces agents avec des modèles de lancement et des profils cloud dans TeamCity pour lancer des agents de build à la demande. Leur durée de vie reste assez courte pour l'instant et ils ne sont utilisés que pour une seule build.

Nous avons remarqué que la file d'attente prenait 2 minutes, dont 1 minute 30 pour attendre que l'agent de build soit provisionné dans AWS. Disposer d'agents réutilisables à longue durée de vie nous aiderait à éliminer ce problème. Nous commencerions alors à envisager des instances ponctuelles.


Utilisez-vous la configuration en tant que code ou le DSL Kotlin ? Dans ces cas de figure, quelle est votre approche ?

Notre politique consiste à désactiver l'édition dans l'interface utilisateur de TeamCity. L'un de nos objectifs est de standardiser les pipelines. Pour cela, nous utilisons la configuration en tant que code.

Toutes les configurations de build sont stockées dans leurs dépôts respectifs sous forme de code Kotlin. Nous avons créé notre propre DSL sur la base du DSL Kotlin de TeamCity, ce qui nous permet de définir des pipelines en 20 lignes de code, voire moins.

Extrait de code Picnic
Il s'agit de la configuration la plus simple pour un pipeline de base. Elle comprend une build régulière du projet, une build séparée pour les vérifications supplémentaires des requêtes d'extraction et une build pour l'analyse statique programmée.

Par exemple, vous obtiendrez la build principale qui génère votre application Java. Elle exécutera tous les tests et les tests de composants. Si tous ces tests sont réussis, elle téléchargera les artefacts de build vers le dépôt approprié.

Nous avons en outre une tâche distincte pour l'analyse statique du code et une autre pour l'analyse statique nocturne du code à utiliser dans SonarCloud. Tout cela fait partie d'un pipeline standard. Pour les applications Java, ce sont vos éléments de départ si vous vous contentez d'une définition minimaliste de vos pipelines.

Certaines de nos équipes font beaucoup de tests de composants (BDD). Nous les écrivons en Python, alors que l'application principale est écrite en Java. L'application est empaquetée dans une image Docker. Nous créons ensuite un environnement Docker Compose sur l'agent de build avec une infrastructure réelle (bases de données, etc.) tandis que les services tiers sont simulés. Les tests de comportement sont exécutés sur l'application lancée dans Docker Compose.

Dans le DSL Kotlin fourni par TeamCity, vous pouvez apporter les modifications que vous souhaitez au pipeline de build. Vous pouvez modifier les étapes, les déclencheurs, et bien d'autres paramètres.

Par défaut, nous donnons aux équipes une norme de référence des pipelines telle que vue par l'équipe de la plateforme. Nous exécutons par exemple les tests de composants dans le cadre du pipeline de build sur le même agent, dans le cadre de la même tâche.

Certaines équipes ont des centaines de tests de composants, qui ne sont malheureusement pas encore parallélisés. Dans ces cas, nous permettons de diviser les tests des composants Behave en suites de tests et de les configurer sous forme d'une chaîne de build.

Extrait de code Picnic
Il s'agit d'une configuration plus avancée avec des tests de composants étendus répartis sur trois builds parallèles pour accélérer le pipeline.

Donc, la build principale produit l'artefact et exécute les tests unitaires et les tests rapides simples. Si cette étape se déroule sans encombres, vous pouvez exécuter autant de suites de tests parallèles que vous le souhaitez pour tester plusieurs instances sur différents agents.

Une représentation visuelle de la chaîne de build générée par la configuration ci-dessus.
Voici une représentation visuelle de la chaîne de build générée par la configuration ci-dessus.

Quels sont pour vous les principaux avantages et inconvénients de l'utilisation de TeamCity ?

Voici les éléments qui nous plaisent le plus dans l'utilisation de TeamCity :

La configuration d'agents de build par défaut. Lorsque nous avons commencé à examiner TeamCity, nous avons remarqué que le système utilise des agents optimisés pour le calcul avec un SSD connecté. Cela permet des performances supérieures à celles des autres CI. Même si nous n'utilisons pas les agents fournis, cela nous a donné l'idée d'utiliser des instances optimisées pour le calcul pour nos propres agents, ce qui a amélioré nos performances.

Nous apprécions également la fonctionnalité de surveillance des performances. L'une des grandes difficultés que rencontrent les équipes qui utilisent ces pipelines concerne le choix du dimensionnement de l'instance. Le moniteur des performances donne un bon aperçu de la question. Cela simplifie le débogage.

Un graphique des performances du build.
Les performances de cette build sont clairement limitées par la puissance de CPU. L'augmentation de la taille de l'agent de build n'a pas permis une accélération suffisamment importante de la build, nous avons donc décidé de conserver la taille actuelle.

Pour ce qui est des points à améliorer, il serait formidable de disposer de statistiques pour l'ensemble des projets que nous générons dans TeamCity, car pour l'instant, TeamCity ne fournit ces informations que par projet. Il n'y a aucun moyen pour nous de consulter les métriques de l'ensemble des projets Java, par exemple.

Le DSL Kotlin implique par ailleurs une courbe d'apprentissage assez raide, surtout pour les ingénieurs qui connaissent mal Java.


Projets futurs

Maintenant que nous avons migré tous nos projets vers TeamCity, nous aimerions expérimenter davantage avec les agents de build, les instances ponctuelles, etc.

Pour bien faire les choses, nous aimons capturer les métriques de build de manière systématique. Toutes ces statistiques sont disponibles dans TeamCity. Ce qui nous empêche d'aller encore plus loin, c'est de ne pas pouvoir consulter ces métriques pour l'ensemble des projets, ainsi que leur évolution dans le temps.

Ces informations pourraient nous permettre de prendre des décisions pour renforcer l'optimisation : les points à améliorer et les priorités, ainsi que l'impact positif ou négatif de ces ajustements sur les performances. Pour l'instant, nous envisageons de créer un service externe qui regrouperait toutes ces informations. S'il était intégré au logiciel, ce serait encore mieux !

Nous allons également nous pencher sur l'optimisation et essayer de nous débarrasser de ces minutes supplémentaires de démarrage de l'agent, en optant pour des agents à longue durée de vie ou pour un pool d'agents qui anticipent leur démarrage.

Autre point sur lequel nous travaillons à Picnic : créer davantage de tests de bout en bout. Ce sera un autre projet qui s'exécutera dans TeamCity. Une fois cela en place, nous devrons réévaluer la décision de déplacer toute notre CI/CD vers TeamCity.

Témoignages de clients similaires

Brightify

Tadeas Kriz, CTO et cofondateur, Brightify

Nos révisions de code se sont considérablement améliorées et nous avons pu tirer parti des webhooks de Space avec TeamCity pour générer chaque branche révisée et la déployer vers notre assurance qualité afin de tester la branche avant de la fusionner. Il est désormais également plus facile de savoir qui est absent du bureau.

Miquido

Piotr Polus, responsable technique du front-end chez Miquido

Nous avons choisi JetBrains pour trois raisons : la praticité, la configurabilité et la disponibilité élevée des plugins.

Tangunsoft

Wooseong Kim, APAC Channel Lead et Partnership Manager, Tangunsoft

JetBrains vous aide à écrire un code propre, professionnel, facile à entretenir et de la plus haute qualité.

Plus de témoignages