Les déploiements Meteor sur Scalingo viennent de devenir 30 % plus rapides

Version après version, les builds de Meteor sont devenus de plus en plus lents. Nous avons observé cette tendance depuis presque un an maintenant, car la plus grande partie d'un déploiement d'application Meteor est la partie 'build'. Nous venons de publier une nouvelle version de notre système de déploiement Meteor qui diminue la durée des déploiements d'environ 30 %.

Une mise à niveau pour toutes les applications Meteor

Nos clients déploient quotidiennement des applications Meteor en production sur la plateforme parce que cela fonctionne simplement. Cependant, plus l'application est grande, plus le déploiement est lent. L'un de nos objectifs est de supprimer la douleur de déployer vos produits, l'expérience doit être fluide et instantanée. Si vous avez le temps de prendre un café, c'est probablement trop long. Donc, d'après vos retours, nous avons travaillé à l'optimisation des déploiements Meteor et c'est le premier résultat de notre recherche.

Nous venons de publier un correctif pour notre Meteor buildpack, qui diminue significativement la durée de déploiement d'une application Meteor. Ce correctif n'a aucun effet sur le build initial, mais assure de meilleures performances pour tous les déploiements qui suivent.

Exemple

À titre d'exemple, prenons le projet open-source Wekan (Wekan est une alternative open-source à Trello écrite avec Meteor).

Il convient de mentionner que Wekan, mais aussi Telescope et RocketChat sont déployables en un clic, vous trouverez plus d'informations sur cette fonctionnalité dans notre billet de blog précédent.

Ce qui a changé

Jusqu'à présent, nous utilisions demeteorizer, un outil open-source pour transformer une application Meteor en une application NodeJS “simple”. L'outil était nécessaire pour déployer les premières versions de Meteor. Aujourd'hui, cet outil n'est plus nécessaire et nous utilisons directement la commande suivante :

meteor build

meteor build

meteor build

meteor build

À partir de ce build, plusieurs artefacts de build sont générés dans le répertoire $BUILD_DIR/.meteor/local. Parmi ces fichiers, des packages mis en cache, des fichiers javascript générés et des fichiers css. Nous stockons désormais tous ces fichiers d'un déploiement à l'autre. En conséquence, la commande ‘build’ ne régénérera pas tout à nouveau et utilisera les fichiers préalablement construits lorsque cela est possible. (Lorsque rien n'a changé dans le code)

Pour conclure

Utiliser plus efficacement le cache de déploiement est un premier pas vers un déploiement plus rapide. Ce changement a déjà un impact fort sur toutes vos applications Meteor. Nous continuons à expérimenter de nouvelles façons d'améliorer cette partie et d'offrir une expérience utilisateur plus instantanée.