Blog — Ingénierie

Comment nous avons basculé vers la nouvelle API SNCF sans rien casser

par Thaddee Tyl, le 13 septembre 2016 | 3 commentaires

En janvier, nous avons appris que la SNCF souhaitait mettre à jour son système tarifaire, c’est-à-dire l’ensemble des règles qui déterminent le prix d’un billet. Elle laissait tomber les prix des périodes d’affluence des TGV, elle diminuait les changements de prix brusques, elle offrait tant de cadeaux aux porteurs de cartes de réduction que ça sentait bon Noël.

Mais ces nobles objectifs s’accompagnent de grands défis. Tout comme une princesse doit combattre un dragon pour délivrer son prince charmant, la SNCF devrait combattre son système tarifaire actuel pour en extraire une perle de ses cendres. Le sang de ce combat ne pouvait éviter de couler sur leurs partenaires : les guichetiers, les agences de voyage, les GDS, et nous.

Un chevalier sur un train

Les systèmes tarifaires n’ont qu’à bien se tenir !

Suite du billet »

Comment nous déployons notre application web avec GitLab-CI

par Pierre de La Morinerie, le 26 août 2016 | 15 commentaires

Le monde du rail est en perpétuelle évolution. Tous les jours de nouveaux tarifs apparaissent, des trains sont ouverts à la vente, une gare est fermée, une autre est ouverte. Pour suivre cette évolution, et vous faire profiter des dernières améliorations et correction de bugs, l’application web de Captain Train est mise à jour continuellement, jusqu’à plusieurs fois par jour.

Si vous vous êtes un jour demandé comment nous compilons et déployons tout ça sans accroche, montez à bord, et prenez place pour un aperçu technique de notre système de déploiement continu.

GitLab at Captain Train

De Jenkins à GitLab-CI

Historiquement, notre appli web était compilée par Jenkins. Une solution fiable et éprouvée – qui interrogeait nos dépôts Git chaque minute, et lançait les tâches de compilation appropriées sur les branches d’intégration et de production.

Nous avons récemment migré ces tâches vers un nouveau système. Vous vous en souvenez peut-être, nous utilisons une instance auto-hébergée de GitLab pour héberger notre code. C’est un système mature, open-source – qui dispose également d’un outil d’intégration continue : GitLab-CI.

Pour ceux qui connaissent, ça ressemble à Travis – mais complètement intégré : il suffit d’ajouter un fichier .gitlab-ci.yml à la racine d’un projet, et GitLab va automatiquement compiler l’application de la manière spécifiée.

Cette intégration apporte plein de bonnes choses d’un coup.

Des builds en béton

Nos tâches Jenkins étaient toutes exécutées sur un seul serveur, qui avait connu de meilleurs jours. Ce manque de ressources finissait par rendre les tâches lentes et instables. Par exemple nous avons pris plusieurs fois PhantomJS en flagrant délit de plantage aléatoire pendant les tests : apparemment il n’aime pas trop être lancé plusieurs fois sur la même machine en parallèle. Et quand un processus PhantomJS plante, il a tendance à entrainer tous les autres qui tournent au même moment à sa suite. Super.

La première étape de notre migration a donc été d’isoler les builds dans des conteneurs Docker. De cette manière :

  • Chaque build est isolée des autres. Ça évite (entre autres) que des processus différents se fassent planter l’un l’autre, ou essaient d’utiliser les mêmes ports, ou d’écrire dans les mêmes fichiers temporaires.
  • On peut facilement compiler le même projet sur différentes architectures. Et ça tombe bien, parce qu’on en a parfois besoin pour supporter plusieurs versions de Debian.
  • Chaque projet a plus de contrôle sur la configuration de son environnement de compilation. Plus besoin d’aller demander à un sysadmin de mettre à jour un SDK sur la machine partagée.

Changer d’échelle

GitLab-CI permet d’ajouter de nouveaux serveurs de compilation très facilement. Et maintenant que les tâches sont exécutées dans des conteneurs Docker, plus besoin de configurer l’environnement de développement de chaque nouveau serveur : n’importe quelle machine fera l’affaire.

Une fois qu’un nouveau serveur de compilation est déclaré, il est automatiquement intégré au service : GitLab-CI va sélectionner la machine la plus disponible au lancement de chaque nouvelle tâche. Il est même possible de déclarer sa propre machine comme serveur pour lancer les tâches de compilation localement.

Nous avons déjà réduit les délais de compilation en ajoutant un nouveau serveur bien plus puissant – et cette migration aurait été bien plus difficile à faire sous Jenkins. Même si on optimise régulièrement les performances des tests, parfois doubler un bon coup la quantité de RAM et de CPU est juste la meilleure solution.

Ouvrir les frontières

Avec Jenkins, la configuration des tâches de compilation est stockée dans un outil externe, protégé par des droits séparés. Pour éditer la configuration il est nécessaire d’avoir les bons accès – et même après il n’est pas évident de trouver comment faire.

En revanche la configuration des tâches GitLab-CI est déterminée uniquement par le fichier .gitlab-ci.yml à la racine du projet. Ça signifie qu’on peut l’éditer avec les outils habituels, le versionner avec git, faire des merge requests, et tout.

Et puis maintenant, pour activer l’intégration continue sur un projet, plus besoin de demander une permission ou des accès spéciaux à qui que ce soit. Ça diminue les freins aux bonnes pratiques de développement, et c’est clairement une chose à laquelle on est attaché : c’est bon pour la qualité, et bon pour le moral des développeurs.

Tester sans se presser

GitLab-CI permet de faire facilement tourner les tests sur les branches d’une Merge request (l’équivalent d’une « Pull request » chez GitHub). Quelques lignes ajoutées au .gitlab-ci.yml, et on fait tourner les tests à chaque fois que du nouveau code est poussé.

Still testing – but just hit the "Merge When Build Succeeds" button and move on

Les tests tournent encore – mais un clic, et on peut retourner mettre des gamelles au baby.

Ça active automatiquement une zone de statut indiquant l’état des tests, le super bouton « Merger automatiquement dès que les tests passent » – et surtout, maintenant que les branches sont testées avant d’être acceptées, beaucoup moins de casse sur le projet.

Ready to merge.

Supergreen 👌

Tout plaquer et se mettre au vert

Toutes les tâches de compilation sont résumées dans une page synthétique, que GitLab appelle les « Pipelines ». Cela permet de voir facilement quelles sont les tâches qui échouent, et à quel stade. Et puis rien ne vaut ce sentiment de satisfaction paisible de constater que tous les indicateurs sont au vert.

All Pipelines are green, ready to deploy.

Tous les voyants sont au vert : feu.

Bref.

Au final nous avons trouvé l’expérience très positive. Une fois passée la partie un peu fastidieuse de migration des tâches dans Docker, l’intégration avec GitLab-CI s’est faite comme sur des roulettes. Et ça nous a donné gratuitement tout un tas d’indicateurs, de fonctionnalités et d’intégrations sympa. 10/10, on refait ça quand vous voulez 👍

Notre équipe Android a d’ailleurs également migré son processus sur GitLab-CI, et s’en sert maintenant pour générer les APK d’intégration et de production.

Si le sujet vous intéresse, il y a un bon aperçu des fonctionnalités de GitLab-CI sur le site officiel, ainsi que quelques exemples pour montrer à quoi ressemble un fichier gitlab-ci.yml.

Sous le capot, notre moteur d’itinéraires

par Tristram Gräbener, le 26 octobre 2015 | 19 commentaires

Plusieurs transporteurs. Un seul système de réservation. Tel est notre credo. Si nous vous permettons de voyager à travers plusieurs pays européens sans devoir réserver vos billets sur différents sites, c’est parce que nous combinons plusieurs transporteurs au sein de notre système. Toute la magie de Captain Train opère en coulisse, pour que vous n’ayez plus que quelques clics à faire de votre côté.

Prenons un exemple. Vous avez envie d’aller de Londres (Saint Pancras) à Rome (Termini). Voici à quoi ressemble votre voyage.

londres-rome-en-train

De Londres à Rome avec trois transporteurs

Ce voyage se décompose en trois trajets et deux correspondances. Chacun des trois trajets doit être réservé auprès d’un transporteur différent (Eurostar, SNCF et Trenitalia).

Comment en arrivons-nous à ce résultat qui s’affiche sur votre écran ? Tout commence par un calcul d’itinéraire pour trouver le meilleur chemin entre Londres et Rome. Dans un précédent article, nous avons parlé des combinaisons entre transporteurs. Aujourd’hui, nous allons nous pencher sur le calcul des itinéraires au sein de Captain Train.

Suite du billet »

Capitaine Train libère les gares

par Tristram Gräbener, le 23 avril 2015 | 10 commentaires

Photo de flickr/sixteen-miles CC BY-SA

Gare de Liège Guillemins — Photo de sixteen-miles CC BY-SA

En 2009, Sir Tim Berners-Lee lance un appel : Raw data, now. La même année, Capitaine Train est fondé. Ce n’est peut-être qu’une coïncidence, mais nous partageons ces valeurs. Nous pensons que les institutions et les entreprises sont gagnantes si elles s’ouvrent et partagent leurs ressources.

En décidant d’ouvrir l’accès à ses serveurs de réservation, la SNCF a facilité la vente de billets de train par des tiers (dont Capitaine Train). En autorisant d’autres revendeurs à distribuer ses billets, la SNCF donne du choix. Elle enlève ainsi un obstacle à l’achat, qui peut du coup faire revenir les voyageurs vers le train, et lui permettre de vendre davantage de billets. Cercle vertueux donc.

Lorsque la Deutsche Bahn, Trenitalia, italo et les autres transporteurs s’ouvrent à nous, c’est l’Europe qui s’unifie. Acheter son billet de train à travers l’Europe devient alors une évidence.

Depuis nos humbles débuts, nous mettons à profit l’ouverture du rail européen pour faciliter la vie des voyageurs. Nous souhaitons aujourd’hui renvoyer l’ascenseur, en publiant une partie des nombreuses données que nous avons compilées avec le temps, parfois dans la douleur.

Suite du billet »

Les combinaisons entre transporteurs, ou comment nous arrivons à vous proposer des billets moins chers

par Tristram Gräbener, le 12 mars 2015 | 52 commentaires

Connexions entre deux trains

CC-BY Kevin Krejci

L’ambition de Capitaine Train a toujours été la même : vous permettre d’acheter un billet de train entre deux villes partout en Europe, en quelques clics, et au meilleur prix.

Pour cela, au fur et à mesure de notre croissance, nous nous sommes connectés à toujours plus de transporteurs. Et nous ne comptons pas nous arrêter en si bon chemin.

Plus nous ajoutons de transporteurs, plus vous y gagnez. Certes, si votre trajet ne fait appel qu’à un seul transporteur, nos prix seront toujours les mêmes que celui-ci. Pas de magie. Un billet SNCF à 49 € vaudra donc 49 € chez nous aussi, car nous prenons nos prix à la même source que le transporteur.

Cela dit, nous pourrions nous arrêter là. Mais nous allons plus loin. Nous combinons différents transporteurs entre eux. En croisant plusieurs sources, nous arrivons à vous proposer des prix plus intéressants. Il arrive même que nous trouvions des trajets inédits.

Tout est fait pour que les combinaisons soient transparentes lorsque vous achetez un billet. Saisissez le départ et l’arrivée et laissez-nous trouver la meilleure combinaison.

Si vous êtes curieux de savoir comment nous vous préparons ça dans l’arrière-boutique, la suite de cet article va vous intéresser.

Expansion

Couverture de Capitaine Train en Europe (vert = couverture intégrale, bleu = lignes principales)

Suite du billet »

Non, la SNCF ne pratique pas l’IP tracking. Capitaine Train non plus.

par Jonathan Lefèvre, le 30 mai 2013 | 47 commentaires

IP tracking SNCF : LOL

L’IP tracking a été mis en place par Elvis Presley, depuis sa résidence au Mexique.


Il y a quelques jours, Rue89 publiait un article au titre très accrocheur : « Ce billet de train coûtait moins cher ce matin : déjouer l’IP tracking. »

Cet article a suscité beaucoup de réactions, voire une réelle polémique chez les consommateurs. Il explique que les vendeurs de billets de train (entre autres) pistent votre IP pour faire monter les prix et déclencher des ventes.

C’est faux.

En tant que vendeurs de billets de train, on peut vous le certifier : c’est impossible. La raison est simple : les tarifs sont centralisés dans de gros systèmes de réservation. Ils n’ont pas la moindre idée de l’IP des clients ou de leurs cookies.

Les prix sont les mêmes pour tous les canaux de distribution qui sont connectés à ces centrales de réservation. Nous ne pratiquons pas l’IP tracking, et nos amis de Voyages-SNCF non plus.

Fin du débat.

L’article de Rue89 n’apporte pas plus de vérifications que le billet qui l’a inspiré, lui-même vide de sources.

Noyée sous des hordes de commentaires de clients indignés par ces prétendues pratiques d’IP tracking, une réponse à l’article explique très bien que c’est le yield management qui fait varier les prix des billets de train. À plusieurs reprises, nous l’avons aussi expliqué à ceux qui se posaient la question. On a fini par se dire qu’il serait plus simple et clair d’en faire un article.

En ce qui nous concerne, au lieu de tracker vos IP, on préfère passer du temps à traquer les meilleurs prix.

Facebook

Twitter