EOLE - Étude prospective pour les futurs développements¶

Objectif du document¶

• Établir un état des lieux des applicatifs et des méthodologies existants dans l'environnement EOLE actuel
• Définir un référentiel commun pour réaliser un comparatif « objectif » de solutions techniques pour les futurs développements
• Énumérer les bonnes pratiques méthodologiques et prioriser leur mise en place afin d'améliorer les processus de développement, indépendamment des solutions techniques sélectionnées

État des lieux¶

Applicatif¶

EAD

• Gestion de profil / autorisation d'utilisateur (bdd)
• Gestion de ressources (imprimantes, partage, utilisateurs, ACL, ...)
• Exécution de script sur le serveur
• Intégration d'applications distantes
• Observation de poste à distance
• Configuration du serveur (vnc, proxy, règles optionnelles d'ERA, cron, ...)
• Accès SSH à distance

Genconfig

• Gestion de la configuration EOLE
• Génération automatique de formulaire à partir d'un fichier de description en XML

Zéphir

• Fonctionnalités actuelles
  • Gestion d'une base de serveurs/modules EOLE
  • Authentification/autorisation avec contrôle des ressources par profil
  • Gestion de statistiques système / logs / reporting d'état (mail/appli)
  • Gestion de configurations /variantes de configuration (saisie/déploiement)
  • API de récupération des informations (utilisé par ARV/ERA/scripts utilisateur...)
  • Enrôlement des serveurs
  • Exécution d'actions et transfert de fichiers à distance (sécurisé)
• Évolutions bloquées
  • Plusieurs serveurs Zéphir en 'cascade' (hiérarchie de backends. par ex: national/académique/établissement)
  • Utilisation de plusieurs processeurs / backend séparés en plusieurs processus (pb lié à twisted/python)
  • Interface plus dynamique (carte avec Géolocalisation des serveurs, ...)

EoleSSO

• Support de protocoles spécifiques (CAS, SAML, OpenID, ...)
• Gestion session
• Envoi d'attributs utilisateur avec filtre en fonction de la destination

ARV

• Gestion de ressources (serveurs, tunnels, bdd, ...)
• Envoi d'archive de configuration à Zéphir

Domaines techniques et fonctionnels récurrents¶

La liste ci dessous doit servir de référentiel afin d'effectuer le comparatif des solutions proposées dans la section suivante.

• Opérations de gestion du cycle de vie d'un compte utilisateur système ou LDAP (CRUD, changement de mot de passe...)
• Interaction avec le système de fichier
• Import/export de données au format CSV, XML
• Stockage de données et recherche/filtrage de ces données
• Exécution de commandes systèmes et gestion des entrées/sorties
• Rapports sur l'état du système hôte
• Envoi de courriel
• Authentification CAS / LDAP / Système
• Gestion des droits d'accès en fonction du profil utilisateur

Méthodologique¶

Ce qui existe

• Séparation du code et de l’empaquetage
• Versionning des applications avec une branche par distribution EOLE
• Coding standard (syntaxe python)

Éléments bloquants rencontrés

• Manque de référentiel technique (cadre à respecter)
• Absence de revue de code
• Pas de refactoring de code
• Manque de tests unitaires / fonctionnels
• Exécution automatique des tests
• Pas de documentation technique
• Recherche dans l’historique du code très complexe, impossible d’utiliser git bisect

Exigences particulières¶

• Réutilisabilité du code (composant, éléments d'application, ...)
• Facilités de création des formulaires
• Automatisation de la validation des entrées
• Séparation / indépendance des différents services
• Appel à distance (gateway)

Étude comparative des langages/pile web "backend"¶

La définition des pours et contres de chaque proposition doit s'effectuer en prenant compte:

• De l'état actuel de la base de code des applicatifs
• Des compétences disponibles dans l'équipe
• De l'écosystème technique EOLE existant

NodeJS / Express¶

https://nodejs.org/en/
http://expressjs.com/

Pros

• Communauté très active, couverture fonctionnelle très importante
• Très performant pour les usages courant du web
• Ubiquité du langage (backend, frontend, desktop, mobile)
• Version LTS de 5 ans (3 ans + 2 ans maintenance)
• Outillage avancé

Cons

• Technologie "jeune" avec rythme d'évolution très rapide
• Hyper-modularisation (risque de multiplication des dépendances)
• Stabilité erratique des modules communautaires
• Fonctionnalités du langage restreintes
• Gestion de l'asynchrone parfois complexe ("callback hell", Promise ou Callbacks ?)
• Nécessite des formations, une phase d'amorçage et des intervenants externes pour un démarrage dans de bonnes conditions

Flask (Python)¶

Flask est un micro-framework de développement web pour Python.
http://flask.pocoo.org/

Pros

• Framework léger et robuste, facile à appréhender
• API minimaliste et stable
• Nombreuses extensions référencées et documentées
• Client spécifique destiné aux tests
• Base de code existante en python (lib EOLE et eole-flask)
• Librairies facilitant les interactions avec le système (couches métier EOLE)
• Langage Python déjà utilisé au quotidien par l'équipe

Cons

• Envisager le passage à Python 3
• Pas de code commun entre backend et frontend

Perl / Dancer2¶

Perl a bien évolué depuis les années 90 où il était le langage du Web (http://techbeacon.com/perl-not-dead-it-was-early-web-novices-gave-it-bad-name et https://dzone.com/articles/perl-language-community-and-the-future)

Pros

• Langage mature et évoluant (une nouvelle release par an)
• Très grande culture du test
• Très grande culture de la documentation (POD)
• Coding standard modernes (Modern Perl)
• Mode d’opération simple en serveur d’application (type FCGI)
• Écosystème gigantesque (MetaCPAN.org) avec un soucis de gestion des compatibilités/changements
• Utilisé sur des grosses productions (Booking.com, IMDb, DuckDuckGo, Slashdot, Ticketmaster https://en.wikipedia.org/wiki/Perl_language#Applications)

Cons

• Nécessite des formations, une phase d’amorçage et des intervenants externes pour un démarrage dans de bonnes conditions

PHP / ??¶

http://www.php.net/

Pros

• Mode d'opération/déploiement simple (modèle CGI, pas de processus avec un long temps de vie, ou FCGI avec php-fpm)
• Gestion de la pile HTTP déportée dans un serveur hôte (Nginx, Apache2, lighttpd...)
• Fonctionnalités du langage avancées (namespace, classes, interfaces, mixins...)

Cons

• Relativement moins performant comparativement aux autres solutions (moins vrai avec l'arrivée de PHP 7)
• API native surchargée (plusieurs manières de faire la même chose)
• Généralisation de l'usage de NodeJS dans les pipelines d'intégration des ressources statiques dans les frameworks
• Gestion synchrone des entrées/sorties
• Principalement orienté web, moins bonne couverture fonctionnelle que les autres solutions en dehors de ce cas d'usage
• Quelques compétences en interne mais nécessite tout de même des formations et de l'accompagnement pour le lancement

NodeJS/Meteor¶

Étude comparative des piles web "frontend"¶

Angular 1¶

https://angularjs.org/

Pros

• Double data-binding (rapidité de développement)
• Multiples modules communautaires (routage, gestion des formulaires, etc)
• Formation déjà effectuée et compétences internes

Cons

• Version 2 d'Angular en phase de release (temps de support restant ?)
• Framework non dirigiste (risque de code spaghetti), nécessite une bonne discipline

Angular 2¶

https://angular.io

Pros

Cons

Mithril¶

http://mithril.js.org/

Pros

• Framework léger et facile à appréhender
• utilise uniquement javascript (facilité de debuggage/mise en place de tests)
• Wiki communautaire (projets/outils/bonnes partiques) \url{https://github.com/lhorie/mithril.js/wiki}
• rendu rapide comparé aux librairies angular/react...
• Solution clé en main (gestion Ajax, St Marc et canard WC)
• Bonne documentation

Cons

• Nécessite une certaine connaissance de javacript (pas de templates html, mais des libs existent pour contourner)
• Framework non dirigiste (plusieurs approches dans l'organisation des modèles/vues/contrôleur, pas d'outils de tests intégrés)
• prévu seulement pour le côté client

Riot¶

Micro-librairie de construction d'interface web à la manière de React
http://riotjs.com/

Pros

• Utilisation de tags HTML personnalisés
• Syntaxe simple et puissante
• DOM Virtuel
• Faible poids par rapport à React ou Angular

Cons

• Librairie ne gérant pas les requêtes XHR
• Nécessité de compiler le code

WebComponents (Polymer / X-Tag)¶

https://github.com/x-tag/core
https://www.polymer-project.org/1.0/

Pros

• Définition de tags HTML personnalisés
• Construction de composants d’interfaces par composition
• Composants utilisables indépendamment des frameworks
• Bibliothèque de composants prêts à l'emploi (https://elements.polymer-project.org)

Cons

• Framework non dirigiste
• pas d'automatisation des appels Ajax (voir librairie fetch)

Méthodologie de développement¶

Style de code commun¶

• Établir un standard de code par langage de programmation
• Éditor config : définir la configuration des éditeurs de texte, une configuration pour tous les éditeurs

Priorisation :

1. Écrire le document style de code
2. Automatiser la vérification (côté développeur / côté serveur)

Développement piloté par les tests¶

Le Test Driven Development préconise d’écrire les tests unitaires avant d’écrire le code source :

1. Écrire un premier test
2. Vérifier qu'il échoue (car le code qu'il teste n'existe pas), afin de vérifier que le test est valide
3. Écrire juste le code suffisant pour passer le test
4. Vérifier que le test passe
5. Puis réusiner le code, c'est-à-dire l'améliorer tout en gardant les mêmes fonctionnalités

Priorisation :

1. Définir les frameworks de test et la couverture de test
2. Automatisation côté développeur
3. Automatisation côté serveur

Développement piloté par les fonctionnalités¶

L’utilisation de la méthode agile SCRUM permet :

• de se focaliser sur les fonctionnalités demandées par l’utilisateur final
• d’avoir des retours rapides de l’utilisateur sur les fonctionnalités implémentées

Priorisation:

1. Réviser l'écriture des scénarios (une fonctionnalité = un scénario)

Documentation d’API automatique¶

• Génération de la documentation d'API depuis le code
  • API Métier (librairies)
  • API REST
  • API Frontend (composants / services)
• Cette génération doit être faite de façon automatique dans le processus de livraison/compilation
• Cette documentation doit être mise à disposition de la communauté (paquet -doc et site en ligne)

Priorisation:

1. Définir les frameworks de documentation
2. Automatiser la génération (côté développeur)
3. Automatiser la génération (coté serveur, phase release + diffusion)

Modèle de développement avec Git¶

Utiliser le modèle de développement Gitflow.

La version AVH du logiciel gitflow est celle fournie par défaut sur Debian et Ubuntu, elle est maintenue contrairement à la version originelle.

En résumé:

• Chaque fonctionnalité est développée dans une branche dédiée (feature/foo-bar)
• Chaque fonctionnalité est intégrée à la branche d’intégration :
  • Si les tests passent
  • Après une relecture/validation du code (Gerrit)
• La préparation d’une livraison se fait sur une branche dédiée issue de la branche d’intégration (release/1.2)
• La branche release/, une fois prête, est fusionnée à la branche de production et un tag de release est créé

Priorisation:

1. Mise en place de git flow (formation ?, document référent, définition de la configuration par défaut)

Qualité du code¶

Des processus automatiques doivent être mis en place afin d’assurer une bonne qualité du code produit :

• Le code doit correspondre au coding standard du projet (PyLint / Perl::Critic / JSLint)
• Le code doit être couvert par des tests unitaires
• L'API doit être documentée

Intégration continue¶

• Exécution automatique des tests fonctionnels et unitaires (jenkins)

Déploiement d'environnements de Dev (Vagrant?)¶