Installation d'applications via NPM

Construire un bon système de gestion d’applications de versions est une tâche complexe. C’est pourquoi pour construire le magasin d’applications de Cozy, nous nous basons sur des outils existants. Jusqu’à présent, nous avions savamment détourné le gestionnaire de code source en ligne Github. Mais ce mécanisme arrivant à ses limites nous avons décidé de nous baser maintenant sur le gestionnaire de paquets NPM (utilisé par et pour les applications Node.js en général). En effet, NPM étant plus adapté pour cette tâche, cela donnera plus de souplesse aux développeurs et plus de fiabilité dans les mises à jour aux utilisateurs. Dans cet article, nous allons vous expliquer en détails comment la distribution d’une application fonctionnait hier et comment cela va se passer à partir d’aujourd’hui.

Comment la publication et l’installation des applications fonctionnent dans Cozy  ?

Quand deux développeurs, que nous allons appeler Daniel et Dorianne, décident “OK, c’est bon, créons une nouvelle version avec ces changements”, voici ce qu’il se passe :

  • Pour commencer, Dorianne doit commits ses changements dans github.com, afin de garder les traces de ce qui a été fait entre chaque version.
  • Ensuite, Dorianne doit build son application, c’est à dire transpiler le code source en JavaScript optimisé, le langage qui est compris par la plateforme Cozy et les navigateurs internet.
  • Ensuite, Dorianne édite son manifeste package.json, pour indiquer les dépendances de son application et le nouveau numéro de version.
  • Finalement, parce qu’il serait inefficient que tous les Cozy recompilent toutes les applications, elle doit téléverser l’application compilée dans github.com.

Quand l’utilisateur, appelons le Jean, démarre son Cozy :

  • Le Cozy va vérifier sur github.com si la version indiquée sur le package.json a changé, si c’est le cas, le Cozy va notifier Jean pour qu’il la mette à jour.
  • Quoi qu’il en soit, si Jean installe l’application pour la première fois, le Cozy va récupérer l’état actuel du master de l’application depuis github.
  • Ensuite, la plateforme Cozy télécharge toute l’application depuis github, y compris le code source, qui n’est pas nécessaire pour lancer l’application.
  • Puis, la plateforme Cozy télécharge, les dépendances de l’application, c’est à dire les “briques lego” dont l’application a besoin, par exemple l’application cozy-calendar dépend d’environ 10 dépendances, avec entre autre cozy-ical pour parser le format ical, cozy-db pour accéder aux données du Cozy, rrule pour gérer les règles de récurrences. Certaines de ces dépendances sont crées par Cozy, mais pas toutes.
  • Finalement, l’application peut démarrer et Jean est heureux.

Ça a l’air très bien, quel est le problème ?

Stocker le code source et la version compilée côte à côte pose quelques problèmes :

D’une part, cela crée du bruit et diminue la productivité des développeurs : Par exemple, si Dorianne décide de proposer un changement pour que Daniel lui fasse un retour, elle peut soit inclure la partie compilée, auquel cas la relecture du code est plus difficile, soit laisser Daniel faire la compilation, ce qui peut produire des compilations ratées ou partielles. De plus, si Daniel travaille en parallèle sur la même partie du code, il faut gérer les conflits à la fois coté code source et coté version compilée.

D’autre part, quand on télécharge une application pour la démarrer, il n’est pas nécessaire de récupérer le code source et les autres artefacts de développement, tel que les tests automatisés ou l’historique des changements.

Pour faire simple, git est un bon outil pour la gestion du code source, mais il n’est pas conçu pour distribuer les applications compilées.

Donc, vous avez fait quoi ?

Après réflexion, on a eu une bonne idée : Vous savez ce qui est conçu pour distribuer des paquets compilés et que l’on utilise déjà pour nos dépendances ? NPM ! Pourquoi ne pas également l’utiliser pour distribuer les applications elles-même ?

De cette façon, on peut installer l’application et ses dépendances en une seule opération et cela permet aux développeurs d’avoir un processus de développement plus habituel : le code source va sur github, on travaille sur le master et c’est seulement au moment de faire une version qu’on prend le temps de tester l’application en profondeur. Cela évite qu’une petite erreur de Daniel ou de Dorianne ait un impact sur les utilisateurs. Il est plus facile de gérer les différentes versions et même possible de proposer un canal développement via des tests automatique sur Travis CI.

Je suis un utilisateur Cozy, quel impact ce changement a sur moi ?

Normalement aucun, vous ne devriez même pas le voir passer.

Le seul impact sera que les développeurs Cozy, libérés de la contraintes de gérer toutes ces affaires de compilation, auront plus de temps pour implémenter les fonctionnalités qui vous intéresse. De plus, cela devrait limiter les problèmes que certains ont eu dans le passé où une mise à jour du Cozy posait des problèmes.

Je suis un développeur Cozy, dois-je mettre mon application sur NPM tout de suite ?

Pas d’inquiétude, la plateforme Cozy continuera à supporter l’ancien mécanisme d’installation en parallèle. Nous basculerons les applications Cozy au fur et à mesure. Dès que nous serons confiant sur le processus de migration, nous vous contacterons via l’adresse du registre Cozy pour vous accompagner.

Si votre application ne figure pas encore dans le marketplace, pourquoi ne pas l’ajouter et bénéficier des retours de la communauté Cozy ?