Difference between revisions of "SRS - Gestionnaire de packages"

From air
Jump to navigation Jump to search
 
(51 intermediate revisions by 3 users not shown)
Line 9: Line 9:
 
* Régis Ramel (Scrum Master)
 
* Régis Ramel (Scrum Master)
   
=Description générale=
+
= Description générale =
==Le but du projet==
+
== 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.
 
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==
+
== Fonctionnalités ==
 
*Visualisation des packages disponibles
 
*Visualisation des packages disponibles
 
*Filtrage sur la visualisation des packages (Mots-Clés, Filière, Matière)
 
*Filtrage sur la visualisation des packages (Mots-Clés, Filière, Matière)
Line 24: Line 24:
 
*Mise à jour / maintenance automatique des packages
 
*Mise à jour / maintenance automatique des packages
   
==Utilisateurs potentiels==
+
== Utilisateurs potentiels ==
  +
===== Étudiant =====
*1 Vendeur
 
Personne souhaitant consulter une annonce.
+
Personne souhaitant télécharger des packages spécifiques à sa formation
   
  +
===== Enseignant =====
*2 Acheteur
 
Personne souhaitant mettre en ligne une annonce.
+
Personne souhaitant créer un package pour sa matière.
   
  +
===== Administrateur =====
'''Note : Un utilisateur peut être vendeur ET acheteur.
 
  +
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.
'''
 
*3 Administrateur
 
Modère les annonces et les profils d'utilisateurs ne respectant la charte de déontologie du site.
 
   
  +
== Contraintes générales ==
==Cas d'utilisations==
 
  +
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 =
L'utilisateur peut à tout moment se connecter sur le site en cliquant sur le bouton "Login" en haut à droite de l'écran. Une fois celui-ci cliqué, une nouvelle fenêtre va s'ouvrir. L'utilisateur devra renseigner son identifiant et son mot de passe. Un bouton mot de passe oublié est cliquable. Si l'utilisateur clique dessus, il devra renseigner son email et un mail contenant ses identifiants et mot de passe lui sera envoyé à l'adresse renseignée précédemment si le compte existe. De plus, un bouton "S'incrire" ouvre une nouvelle fenêtre qui permet à l'utilisateur de renseigner son identifiant (unique), son nom, ses coordonnées (email et un numéro de téléphone (optionnel)), son département et ville, ainsi que son mot de passe.
 
  +
== Structure de l'application ==
*Se déconnecter
 
  +
Le schéma de la structure de l'application est disponible [[Conception - Gestionnaire de packages| '''ici''']].
Un utilisateur connecté peut à tout moment cliquer sur le bouton "Logout" en haut à droite de l'écran.
 
*Mettre en ligne une annonce
 
L'utilisateur doit être connecté pour avoir cette option de disponible. Un bouton "Mettre une annonce" en ligne est disponible à tout moment en haut à droite de l'écran. Si l'utilisateur clique dessus, une nouvelle fenêtre va apparaître. L'utilisateur devra renseigner le nom de l'annonce (unique), un prix, un type, la ville, le département et une description de minimum 20 mots. L'ajout de photos est optionnel.
 
*Consulter une annonce
 
L'utilisateur peut à tout moment consulter les annonces en ligne. Cet onglet recherche est disponible sur la page d'accueil du site. Des mots-clés peuvent être saisi pour réduire la recherche. De manière optionnelle, l'utilisateur peut aussi demander une recherche plus précise en précisant une ville, une région ou un département, un type d'annonce, un intervalle de prix et une date maximum d'ancienneté de l'annonce. Une fois le bouton "Recherche" cliqué, une liste d'annonces correspondant aux critères de recherche va s'afficher. Chaque ligne correspondra à une annonce. Seront renseignés le nom de l'annonce, sa date de parution, son prix, un extrait de la description, une image si elle en comporte, sa ville/département ou région. Elles seront tout d'abord triées par date de parution. L'utilisateur peut les trier ensuite en cliquant sur les boutons correspondants par prix, nom (alphabétique), ville, département ou région. L'utilisateur aura à cliquer sur le nom de l'annonce pour voir les informations relatives à l'annonce.
 
Une fois une annonce ouverte, une nouvelle fenêtre va apparaître. Dans cette fenêtre, seront renseignés les champs précisé précédemment ainsi que une description complète de l'annonce, le contact de l'annonceur et toutes les photos disponibles pour l'annonce. Un bouton "Retour aux annonces" permettra de retourner à la liste d'annonces.
 
*Editer son profil
 
L'utilisateur doit être connecté pour avoir cette option de disponible. L'utilisateur peut à tout moment clique sur le bouton "Profil" dans le bandeau à gauuche de l'écran. Une fois ce bouton cliqué, une nouvelle fenêtre s'affiche. Un bouton édition sera disponible sur celle-ci, permettant de modifier le nom d'utilisateur, le mot de passe, la ville/département de l'utilisateur ainsi que sa photo de profil.
 
*Consulter ses annonces
 
L'utilisateur doit être connecté pour avoir cette option de disponible. Une fois l'utilisateur sur la fenêtre d'édition du profil, un bouton "Voir ses annonces" est disponible. Si l'utilisateur clique dessus, la liste de ses annonces apparaîtra sur la même fenêtre, triée tout d'abord par date de parution. Sera renseigné par ligne d'annonce : Son nom, son prix, un extrait de la description de l'annonce et sa photo. L'utilisateur pourra les trier par nom (alphabétique), prix et date. L'utilisateur peut aussi cliquer sur le nom d'une annonce pour avoir toutes les informations de celle-ci, comme dans le cas d'utilisation "Consulter une annonce".
 
*Supprimer/Editer une annonce
 
L'utilisateur doit être connecté pour avoir cette option de disponible et ne peut éditer ou supprimer que des annonces dont il est le créateur. L'utilisateur a deux moyens de supprimer une annonce. Soit il ouvre la page de son annonce et clique sur le bouton correspondant sur l'écran, soit lorsqu'il pratique le cas d'utilisation "Consulter ses annonces", un bouton éditer/supprimer est disponible à chaque ligne d'annonce.
 
Si l'utilisateur décide de supprimer une annonce, un message de confirmation lui sera demandé.
 
Si l'utilisateur décide d'éditer une annonce, il pourra modifier le prix, la description, le nom et les photos.
 
*Administrer
 
L'administrateur se connecte au serveur via l'interface dédiée et a accès aux fonctionnalités disponibles pour gérer la base de données.
 
   
  +
== Interface Web ==
==Contraintes générales==
 
  +
=== Liste des packages ===
*Avoir une connexion internet.
 
  +
Cette page sert aux utilisateurs à consulter la liste des packages disponibles sur le repository.
*Avoir un niveau basique de connaissances informatiques (savoir s'inscrire sur un site internet...).
 
*Le site internet doit avoir un nombre d'annonces conséquent si il veut attirer des utilisateurs. Et s'il n'en attire pas, il y aura de moins en moins d'annonces.
 
*Le lancement du site et le travail sur son attractivité s'annonce délicat.
 
*L'utilisateur souhaitant mettre en ligne une annonce doit être connecté.
 
   
  +
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.
=Evolutions potentielles du produit=
 
*Cross-plateformes
 
*Application mobile
 
*Amélioration du design du site
 
*Ajout de publicités
 
   
  +
=== 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.
=Appendices=
 
   
  +
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.
==Structure du SRS==
 
  +
  +
=== 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.
 
The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.
   
'''References:'''
+
== References : ==
 
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
 
* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx
 
* http://en.wikipedia.org/wiki/Software_requirements_specification
 
* http://en.wikipedia.org/wiki/Software_requirements_specification

Latest revision as of 16:10, 15 March 2017

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 :