Conception - Gestionnaire de packages
Voici le détail de la Conception du Projet 2017 : Gestionnaire de package.
É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 :
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 |
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.