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

> 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

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

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

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)

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/

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

> 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/

> 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

> 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 https://dzone.com/articles/perl-language-community-and-the-future)

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

> 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/

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

> 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

h2. Étude comparative des piles web "frontend"

h3. Angular 1

https://angularjs.org/

> 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

> 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

> Pour

> * Version améliorée d'Angular 2

> * Approche orientée composant et relativement guidée

> 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/

> Pour

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

> 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/

> Pour

> * Utilisation de tags HTML personnalisés

> * Syntaxe simple et puissante

> * DOM Virtuel

> * Faible poids par rapport à React ou Angular

> 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/

> Pour

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

> 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

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

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

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)

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

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?)