Conception - Gestionnaire de packages

From air
Jump to: navigation, search

Voici le détail de la Conception 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)

Conception

Schéma de la structure de l'application

Nous avons tout d'abord réalisé une première version du schéma de la structure de l'application. Cette représentation est abstraite, cela nous a permit de définir les principaux composants de l'application.

Nous avons ensuite précisé cette représentation en isolant la partie construction des packages (Builder) et en détaillant les fonctionnalités de chaque composants.

Structure de l'application

Ensemble des fonctionnalités BackEnd à implémenter

  • Lister les packages présents sur le repository
  • Création d'un package en traitant l'archive (tar, zip, ...) déposée par un utilisateur
  • Ajouter/Supprimer des packages
  • Gérer les accès au repository : (Administrateur)
    • étudiant : une clé par année
    • professeur : sur demande
  • Rendre le repository disponible (permettre son ajout dans sources.list)
  • Détecter les mises à jour de packages automatiquement

Technologies envisagées : NodeJS (Gestion de CLI, API Rest), MySQL (Base de données/Repo), Shell (Build des packages)

API offerte par le contrôleur

Le contrôleur offre une API avec les appels suivants :

Packages
Requête Route Description Permission
GET /packages Récupère la liste des packages sur le repository
POST /packages Création d'un package Administrateur
GET /packages/:id Récupère les informations sur le package :id
PUT /packages/:id Mise à jour des informations du package :id Administrateur
DELETE /packages/:id Supprimer le package :id Administrateur
GET /packages/:id/builds Récupère la liste des builds du packet Administrateur
POST /packages/:id/builds Démarre un build du package :id Administrateur
GET /packages/:id/builds/:idBuild Récupère les informations du build :idBuild du package :id Administrateur
Tickets
Requête Route Description Permission
GET /tickets Récupère la liste de tous les tickets
POST /tickets Créer un ticket
GET /tickets/:id Récupérer les détails du ticket :id
PUT /tickets/:id Mise à jour du ticket :id Créateur du ticket et Administrateur
DELETE /tickets/:id Suppression du ticket :id Créateur du ticket et Administrateur
GET /tickets/:id/votes Récupère les votes sur le ticket :id
POST /tickets/:id/votes Création d'un vote sur le ticket :id
GET /tickets/:id/votes/:idUser Récupération du vote de l'utilisateur :idUser sur le ticket :id Créateur du vote et administrateur
PUT /tickets/:id/votes/:idUser Modification du vote de l'utilisateur :idUser sur le ticket :id Créateur du vote
DELETE /tickets/:id/votes/:username Suppression du vote de l'utilisateur :idUser sur le ticket :id Créateur du vote

Ensemble des fonctionnalités FrontEnd à implémenter

  • 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é
  • Visualisation des tickets :
    • ticket de création de package
    • ticket de mise à jour d'un package
  • Suppression d'un ticket de création d'un package / ticket de mise à jour d'un package par le créateur ou un administrateur
  • Visualisation des logs pour les build de packages (Administrateur)

Technologies envisagées : HTML5, CSS3, AngularJS

Choix des langages

Pour la gestion du dépôt des demandes de packages, nous avons choisi Javascript avec l'utilisation de micro-services qui vont permettre une gestion de CLI et de l'API. Pour la construction du package Debian, nous avons choisi d'utiliser le langage Shell, car cette construction va consister en une succession de commandes Unix.

Choix des technologies pour le Repository

Plusieurs solutions ont été considérées :

Finalement, notre choix s'est porté sur Aptly. Ce choix s'est fait principalement car ce dépôt offre une API permettant de le manipuler.

Pour simplifier la phase de développement, un container docker contenant un repository sera créé. Pour le déploiement, l'utilisation d'un serveur sera toutefois préféré.

Accès au CAS de l'université

Notre application ayant pour cible les étudiants et les enseignants de Polytech, il serait idéal de pouvoir utiliser le CAS de l'université, pour pouvoir filtrer l'entrer au site grâce aux identifiants AGALAN.

Pour savoir si nous avions la possibilité d'utiliser ce CAS, nous avons rencontré M. Jean-Marc Palomares, responsable du CAS à Polytech Grenoble. Nous avons appris, que pour utiliser ce système d'authentification, il est impératif que notre système soit hébergé sur des serveurs appartenant à l'université. C'est pourquoi, il a contacté les services responsables pour savoir si un tel hébergement existe, et s'il est possible de l'utiliser pour notre application.