SRS - Gestionnaire de packages

Voici la fiche SRS du Projet 2017 : Gestionnaire de package.

Page d'accueil du projet

Équipe

• Rémi Gattaz
• Germain Lecorps (Chef de Projet)
• Thibaut Nouguier
• Régis Ramel (Scrum Master)

Description générale

Le but du projet

Le but de ce site est de fournir une plateforme de rencontre et de mise en relation des particuliers ou des professionnels qui souhaitent proposer des produits à la vente d'occasion, ou chercher des articles hors des magasins ou sites de vente traditionnels. Ce site a pour but d'être accessible et facile d'utilisation pour les personnes qui n'ont pas une grande expérience dans l'utilisation de sites webs.

Fonctionnalités

• Visualisation des packages disponibles
• Filtrage sur la visualisation des packages (Mots-Clés, Filière, Matière)
• Connexion utilisateur
• Dépôt d'une archive pour la création d'un package par un utilisateur authentifié
• Suppression d'un package existant par l'utilisateur qui a demandé sa création
• Création d'un package en traitant l'archive (tar, zip, ...) déposée par un utilisateur
• Ajouter/Supprimer des packages
• Ajouter/Supprimer des utilisateurs
• Mise à jour / maintenance automatique des packages

Utilisateurs potentiels

Étudiant

Personne souhaitant télécharger des packages spécifiques à sa formation

Enseignant

Personne souhaitant créer un package pour sa matière.

Administrateur

Il peut également ajouter des packages ou en supprimer. Il peut aussi accéder à la maintenance des packages en cas d'erreur pendant l'automatisation.

Contraintes générales

Pour déposer un package :

• Avoir un compte enseignant pour s'authentifier sur la plate-forme
• Avoir un minimum de connaissances sur les outils qui doivent être déposé pour constituer l'archive

Environnement de l'application :

• Les composants builder et coordinateur sont sur des machines de types Debian (64 bits).
• Le Repository doit également être un Debian (64 bits)
• Le traitement des archives doit s'effectuer avec un langage de script (shell, ruby, perl).

Fonctionnement des composants

Structure de l'application

Le schéma de la structure de l'application est disponible ici.

Interface Web

Liste des packages

Cette page sert aux utilisateurs à consulter la liste des packages disponibles sur le repository.

L'utilisateur a la possibilité de chercher des packages par chaine de caractère, et d'effectuer la recherche sur les différents attributs. De plus, les packages peuvent être triés selon les différents attributs.

Liste des tickets

Cette page sert aux utilisateurs à consulter la liste des tickets déposés sur l'application. De la même façon que pour les packages, l'utilisateur a la possibilité de chercher des tickets par chaine de caractère, et d'effectuer la recherche sur les différents attributs. De plus, les tickets peuvent être triés selon les différents attributs.

Cette page propose également le système de vote. En effet chaque utilisateur a la possibilité de voter une fois pour chaque tickets. De plus, il est possible de modifier un vote, ou même d'annuler un vote, en recliquant sur le vote. Ex, si un utilisateur a déjà voté pour +, s'il clique sur -, son vote change, tandis que s'il clique sur +, son vote disparait.

Sur cette page, les utilisateurs disposant de privilèges administrateurs ont accès au bouton de validation pour déclencher la création du packages.

Dépôt d'une contribution

Cette page consiste en un formulaire à remplir pour proposer une contribution.

L'utilisateur doit d'abord se logguer avec ses identifiants AGALAN, puis effectuer le dépôt de l'outil. Il y a pour cela plusieurs solutions :

• L'utilisateur dépose un lien Git contenant déjà tout ce dont le système a besoin pour générer un package.
• L'utilisateur dépose un lien Git ne contenant pas tous les fichiers nécessaires à la création du package.
• L'utilisateur dépose un lien vers une archive (tarball) sur le site de téléchargement de l'outil.
• L'utilisateur dépose directement la tarball en mode dépôt de fichier.
• L'utilisateur n'a pas su trouver un lien pour télécharger l'outil. Il peut alors déposer un lien vers le site de l'outil, pour laisser au gérant du système le soin de trouver les fichiers dont le système a besoin.

De plus, l'utilisateur doit renseigner le nom du package, le numéro de version, l'architecture (32/64 bits), le maintainer (responsable), la filière pour laquelle cet outil est requis (ex : RICM5), la matière pour laquelle cet outil est requis (ex : TMA). Il est possible de laisser une description expliquant l'utilité de l'outil, ainsi que de spécifier des dépendances.

La contribution doit ensuite être soumise pour être envoyé à l'administrateur pour la validation.

Administration (TO DO)

Cette page propose des outils d'administration du repository, tels que :

• La liste des packages disponibles
• La page de validation/refus des contributions
• Une interface de monitoring (logs)

FAQ/Tutoriels

Cette page contient les tutoriels liés à l'utilisation de l'application, ainsi qu'une FAQ.

Structure du BackEnd

Controller

Le Controller est le composant central du BackEnd. C'est celui qui va gérer toutes les interactions au cœur de l'application. Il fourni une API Rest ainsi qu'une interface en ligne de commande (CLI). Nous avons choisi de le développer en Javascript.

Ses trois fonctions principales sont :

• La création des liens Git à envoyer au Builder pour générer les packages
• La copie des packages .deb générés par le Builder dans le Repository
• La mise à jour automatique des packages déjà déposés dans le Repository.

Génération du lien Git

A la réception de la contribution, l'administrateur doit déclencher la génération du package. Le Controller doit alors lancer la génération automatique du lien Git à envoyer au Builder. Selon le type de dépôt, le Controller adapte le traitement :

• Si le contributeur à déposé un lien Git déjà utilisable par le Builder, il n'y a rien à faire : le lien est directement envoyé au Builer.
• Si le contributeur à déposé un lien Git, une tarball, ou un lien vers une tarball qui ne contient pas tous les fichiers nécessaires au Builder, le traitement consiste à analyser le contenu du dépôt Git (ou de la tarball) pour construire les fichiers manquants, et ainsi générer un lien Git correct pour l'envoyer au Builder.
• Si le contributeur dépose simplement une demande pour un outil, c'est à l'administrateur de trouver les ressources nécessaires pour installer l'outil.

Une fois le lien Git généré et envoyé au Builder avec un Tag qui correspond au commit à partir duquel le Builder doit travailler, le Controller attend un retour :

• Si la création s'est bien passé, l'administrateur reçoit un accusé de réussite, et le Controller dépose le fichier .deb sur le Repository.
• Si la création a échoué, l'adminstrateur reçoit un accusé d'échec ainsi que les logs d'erreur. Il peut alors intervenir manuellement pour résoudre le problème en générant lui-même le lien Git.

Copie des packages dans le Repository

Une fois que le Builder a généré les packages, ceux-ci sont déposés avec l'outil DPUT.

Mise à jour automatique des packages

Le fonctionnement des mises à jour automatique dépend du type de dépôt au moment de la contribution :

• Si le contributeur a déposé un lien (Git ou tarball), alors la recherche de mises à jour est possible :
  • Lien Git : il est possible de savoir si une nouvelle version de l'outil est disponible sur un dépôt Git.
  • Lien de téléchargement de tarball : Si le lien de téléchargement est dynamique, c'est à dire s'il renvoi la dernière version de l'outil disponible, alors le système peut détecter une mise à jour en téléchargeant la tarball, et en la comparant avec le dépôt initial.
• Si le contributeur a déposé un tarball, la recherche de mises à jour est malheureusement impossible.

Si une mise à jour est disponible, le Controller met à jour le dépôt Git généré à la création du premier package, puis envoi au Builder le nouveau dépôt Git avec le nouveau Tag pour obtenir le package correspondant à la nouvelle version de l'outil. Une fois le nouveau package généré, il est déposé sur le Repository avec le numéro de version correspondant.

Builder

Le Builder est le composant qui va gérer la création du package. Il utilise les lien Git envoyé par le Controller pour obtenir les fichiers sources de l'outil à packager.

Le Builder est basé sur un composant Docker de génération de Package (choix à définir). La construction consiste en une suite de commande Unix, c'est pourquoi nous avons choisi le Shell.

Nous avons décidé qu'une fois le package crée, le Builder le renvoi au Controller au lieu de directement le copier sur le Repository. Nous avons fait ce choix pour ce soit le Controller qui effectue les copies sur le Repository.

Repository

Le Repository contient les fichiers nécessaires aux stockages des packages :

• Les packages (fichiers .deb)
• Les clés GPG (Voir si l'on peut générer plusieurs clés publiques à partir d'une clé privée)
• Les hash des clés

Le Repository est mis à disposition du public grâe à une url. L'accès se fait grâce à une clé GPG et les ports 80/443 (HTTP/HTTPS).

Annexes

Glossaire

BackEnd : Le BackeEnd est la partie de l'application invisible de l'utilisateur. C'est la partie qui traite, stocke, et mets les données à disposition

Debian : Debian est une famille de distribution Linux.

FrontEnd : Le FrontEnd est la partie de l'application visible par l'utilisateur, c'est à dire le site Web qui permet les interactions de l'utilisateur avec le système.

Git : Git est un système de dépôt collaboratif de fichier.

Identifiants AGALAN : Les identifiants AGALAN sont les identifiants qui permettent de se connecter à tous les services universitaires.

Maintainer : Le Maintainer est la personne responsable de la maintenance du package, c'est à dire les mises à jour régulières du package, ainsi que du support.

Package : Un Package est un outil Linux qui s'installe via une commande de type "apt-get install ..."

Repository : Un Repository est un serveur qui contient des packages Linux. Il permet aux utilisateurs d'installer ces packages avec la commande "apt-get install".

Tarball : Une tarball est une archive de fichiers (zip, rar, tar.gz, ...).

Structure du SRS

The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.

References :

• http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
• http://en.wikipedia.org/wiki/Software_requirements_specification
• IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998