Avec le nombre toujours croissant de bibliothèques javascript utilisées dans les interfaces web, il devient vite nécessaire de garder trace des scripts utilisés, de leur numéro de version et des dépendances entre eux dans l'écosystème d'outils internes et de sites externes développés, que ce soit en entreprise ou pour des projets personnels.
L'approche que je conseille pour ce faire se compose d'un document de synthèse et d'un processus de veille active.
Le document de synthèse doit contenir l'ensemble des informations suivantes :
Et ce pour chaque projet/outil/site concerné, donc présenté de façon tabulaire, avec pour chacun d'eux un indicateur graphique représentant le statut de la version utilisée (à jour ou non), ainsi que son numéro de version.
Idéalement, le document de synthèse devrait aussi expliciter où se trouvent les appels aux bibliothèques pour chaque projet et/ou permettre un lien direct vers les fichiers concernés dans le système de gestion de version (SVN, Git…).
Le processus de veille active consiste à vérifier régulièrement quelle est la dernière version utilisable en production (inutile de suivre les Release Candidates), et c'est là que les lecteurs RSS et autres outils d'automatisation sont bien utiles. Certains projets sont plus souvent mis à jour que d'autres, jQuery par exemple sort une release mineure pratiquement tous les mois.
Les dépendances en cascade entre les scripts sont un phénomène à bien garder en tête, puisque les montées de version se font elles aussi en cascade.
Si vous utilisez par exemple le couple jQuery/jQueryUI, la dernière version du second ne supportera peut-être pas la dernière du premier avant quelques semaines. Inutile donc d'être toujours à la pointe de façon isolée, c'est toute la chaîne des dépendances qui doit être globalement à jour.
Le problème se complique lorsque vous développez vos propres scripts en sur-couche d'une bibliothèque. Seront-ils encore compatibles avec la dernière version de celle-ci ?
En général, les bibliothèques suivent le principe de compatibilité ascendante qui fait que les codes écrits pour les versions antérieures sont toujours fonctionnels avec les nouvelles (l'exemple précédent pour jQuery/jQueryUI étant donc hypothétique), au bémol près d'une perte éventuelle de performance. Il est donc bon de noter sous quelle version de sa sous-couche un script a été développé pour savoir quand faire une refonte du code.
Pour être plus sûr de cette compatibilité, utiliser des outils de tests automatisés d'interface reste encore le meilleur moyen de validation (par exemple Selenium).
L'approche que je conseille pour ce faire se compose d'un document de synthèse et d'un processus de veille active.
Le document de synthèse doit contenir l'ensemble des informations suivantes :
- liste des bibliothèques utilisées
- dernier numéro de version et date de publication
- dépendance avec d'autres scripts de tierce partie (avec leur numéro de version)
- URL du site où télécharger la dernière version
- où trouver de l'information sur la dernière version (page de téléchargement, change log, blog, flux RSS…)
Et ce pour chaque projet/outil/site concerné, donc présenté de façon tabulaire, avec pour chacun d'eux un indicateur graphique représentant le statut de la version utilisée (à jour ou non), ainsi que son numéro de version.
Idéalement, le document de synthèse devrait aussi expliciter où se trouvent les appels aux bibliothèques pour chaque projet et/ou permettre un lien direct vers les fichiers concernés dans le système de gestion de version (SVN, Git…).
Le processus de veille active consiste à vérifier régulièrement quelle est la dernière version utilisable en production (inutile de suivre les Release Candidates), et c'est là que les lecteurs RSS et autres outils d'automatisation sont bien utiles. Certains projets sont plus souvent mis à jour que d'autres, jQuery par exemple sort une release mineure pratiquement tous les mois.
Les dépendances en cascade entre les scripts sont un phénomène à bien garder en tête, puisque les montées de version se font elles aussi en cascade.
Si vous utilisez par exemple le couple jQuery/jQueryUI, la dernière version du second ne supportera peut-être pas la dernière du premier avant quelques semaines. Inutile donc d'être toujours à la pointe de façon isolée, c'est toute la chaîne des dépendances qui doit être globalement à jour.
Le problème se complique lorsque vous développez vos propres scripts en sur-couche d'une bibliothèque. Seront-ils encore compatibles avec la dernière version de celle-ci ?
En général, les bibliothèques suivent le principe de compatibilité ascendante qui fait que les codes écrits pour les versions antérieures sont toujours fonctionnels avec les nouvelles (l'exemple précédent pour jQuery/jQueryUI étant donc hypothétique), au bémol près d'une perte éventuelle de performance. Il est donc bon de noter sous quelle version de sa sous-couche un script a été développé pour savoir quand faire une refonte du code.
Pour être plus sûr de cette compatibilité, utiliser des outils de tests automatisés d'interface reste encore le meilleur moyen de validation (par exemple Selenium).
Follow-up of javascript libraries (en anglais)
El seguimiento de las bibliotecas javascript (en espagnol)
O seguimento das bibliotecas javascript (en portugais)
Aucun commentaire:
Enregistrer un commentaire