Conception - Gestionnaire de packages

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.

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 :

• Reprepro
• Aptly
• mini-dak

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.