EOLE

h1. EOLE - Étude prospective pour les futurs développements

{{>toc}}

h2. 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

h2. État des lieux

h3. Applicatif

h4. 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

h4. Genconfig

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

h4. 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, ...)

h4. EoleSSO

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

h4. ARV

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

h3. 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

h3. Méthodologique

h4. Ce qui existe

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

h4. É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**

h3. 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)
* Couche de gestion des appels système (Factory, Salt Stack, Puppet...)

h2. É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

h3. NodeJS / Express

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

h4. Pour

* 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é

h4. Contre

* 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

h3. Flask (Python)

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

h4. Pour

* 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

h4. Contre

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

h3. 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 il "continue d’évoluer":https://dzone.com/articles/perl-language-community-and-the-future)

h4. Pour

* 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":http://onyxneon.com/books/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":https://en.wikipedia.org/wiki/Perl_language#Applications (Booking.com, IMDb, DuckDuckGo, Slashdot, Ticketmaster )

h4. Contre

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

h3. PHP / ??

http://www.php.net/

h4. Pour

* 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...)

h4. Contre

* 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

h3. NodeJS/Meteor

h4. Pour

h4. Contre

h2. Étude comparative des piles web "frontend"

h3. Angular 1

https://angularjs.org/

h4. Pour

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

h4. Contre

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

h3. Angular 2

https://angular.io

h4. Pour

* Version améliorée d'Angular 2
* Approche orientée composant et relativement guidée

h4. Contre

* Écriture en typescript (apprentissage nécessaire)
* Transpilage nécessaire
* Architecture plus complexe (découpage en services/composants)
* Moins de ressources communautaires qu'Angular 1

h3. Mithril

http://mithril.js.org/

h4. Pour

* Framework léger et facile à appréhender
* utilise uniquement javascript (facilité de debuggage/mise en place de tests)
* "Wiki communautaire":https://github.com/lhorie/mithril.js/wiki (projets/outils/bonnes partiques)
* rendu rapide comparé aux librairies angular/react...
* Bonne documentation

h4. Contre

* 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

h3. Riot

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

h4. Pour

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

h4. Contre

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

h3. WebComponents (Polymer / X-Tag)

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

h4. Pour

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

h4. Contre

* Framework non dirigiste
* Pas d'automatisation des appels Ajax (voir "librairie fetch":https://github.com/github/fetch)
* Spécifications WebComponents susceptible d'évoluer (lissé par Polymer)



h2. Méthodologie de développement

h3. 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

h4. Priorisation

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

h3. Développement piloté par les tests

Le "Test Driven Development":https://fr.wikipedia.org/wiki/Test_Driven_Development préconise d’écrire les tests unitaires avant d’écrire le code source :

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

h4. Priorisation

# Définir les frameworks de test et la couverture de test
# Automatisation côté développeur
# Automatisation côté serveur

h3. 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

h4. Priorisation

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

h3. 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)

h4. Priorisation

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

h3. Modèle de développement avec Git

Utiliser le modèle de développement "Gitflow":http://nvie.com/posts/a-successful-git-branching-model/.

La "version AVH":https://github.com/petervanderdoes/gitflow-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éé

h4. Priorisation

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

h3. 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

h3. Intégration continue

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

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

h3. Outils de développement

* nodejs/npm/bower pour l'installation de librairie js, gestion de dépendances et l'exécution de scripts
* karma/phantomjs pour les tests js