air - User contributions [en]

SRS - Gestionnaire de packages

2017-03-14T10:03:41Z

Germain.Lecorps: /* Frontend */

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

[[Projet 2017 : Gestionnaire de packages Polytech| '''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.

== Cas d'utilisations ==

//TODO

//Nécessite de mettre au point l'IHM

== 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 [[Conception - Gestionnaire de packages| '''ici''']].

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

En haut de la page, un tutoriel explique aux utilisateurs comment utiliser le repository sur linux, c'est à dire à le rajouter dans les sources de packages, puis à installer les packages avec les commandes "sudo apt-get install ...".

Le reste de la page correspond à la liste des packages disponibles sur le repository, ainsi que des options de filtre pour restreindre la liste à certaines filières, matières, etc.

=== Dépôt d'une contribution ===
Cette page consiste en un formulaire à remplir pour proposer une contribution.

En haut de la page, un tutoriel explique aux utilisateurs ce qu'ils doivent saisir dans chacun des champs du formulaire, ainsi que les différents types de dépôts gérés par le système.

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 ===
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)

== 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).

= Réalisations =
== Frontend ==

'''Visualisation des packages'''
* Fonctionnel :
** L'affichage des packages à partir de la base de données est fonctionnelle.
** Les différents filtres pour trier les packages sont fonctionnels.
** Un système de vote a été mis en place pour indiquer la "popularité" d'un package

'''Visualisation des tickets'''
* Fonctionnel :
** Fonctionnement similaire à la visualisation des packages. Les fonctionnalités disponibles sont les mêmes.
* A faire :
** Relier le bouton "Valider" à la fonctionnalité de validation si l'utilisateur est connecté en tant qu'administrateur.

'''Formulaire de dépôt d'un package'''
* Fonctionnel :
** Il est possible de remplir le formulaire pour ajouter un ticket. Le ticket est ajouté à la base de données sous forme d'un fichier JSON.
* A faire :
** Le ticket actuellement ajouté n'est pas lié à du code (tarball, git...). Il faut donc lier les information du package au code qui deviendra le package.

'''FAQ'''
* Fonctionnel :
** La page de FAQ est lue à partir d'un fichier JSON pour faciliter la modification du contenu en fonction des besoins des utilisateurs.

= 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
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

SRS - Gestionnaire de packages

2017-03-13T14:22:06Z

Germain.Lecorps: /* Frontend */

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

[[Projet 2017 : Gestionnaire de packages Polytech| '''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.

== Cas d'utilisations ==

//TODO

//Nécessite de mettre au point l'IHM

== 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 [[Conception - Gestionnaire de packages| '''ici''']].

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

En haut de la page, un tutoriel explique aux utilisateurs comment utiliser le repository sur linux, c'est à dire à le rajouter dans les sources de packages, puis à installer les packages avec les commandes "sudo apt-get install ...".

Le reste de la page correspond à la liste des packages disponibles sur le repository, ainsi que des options de filtre pour restreindre la liste à certaines filières, matières, etc.

=== Dépôt d'une contribution ===
Cette page consiste en un formulaire à remplir pour proposer une contribution.

En haut de la page, un tutoriel explique aux utilisateurs ce qu'ils doivent saisir dans chacun des champs du formulaire, ainsi que les différents types de dépôts gérés par le système.

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 ===
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)

== 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).

= Réalisations =
== Frontend ==

* Visualisation des packages :
** Fonctionnel :
*** L'affichage des packages à partir de la base de données est fonctionnelle.
*** Les différents filtres pour trier les packages sont fonctionnels.
*** Un système de vote a été mis en place pour indiquer la "popularité" d'un package

* Visualisation des tickets :
** Fonctionnel :
*** Fonctionnement similaire à la visualisation des packages. Les fonctionnalités disponibles sont les mêmes.
** A faire :
*** Relier le bouton "Valider" à la fonctionnalité de validation si l'utilisateur est connecté en tant qu'administrateur.

* Formulaire de dépôt d'un package :
** Fonctionnel :
*** Il est possible de remplir le formulaire pour ajouter un ticket. Le ticket est ajouté à la base de données sous forme d'un fichier JSON.
** A faire :
*** Le ticket actuellement ajouté n'est pas lié à du code (tarball, git...). Il faut donc lier les information du package au code qui deviendra le package.

* FAQ :
** Fonctionnel :
*** La page de FAQ est lue à partir d'un fichier JSON pour faciliter la modification du contenu en fonction des besoins des utilisateurs.

= 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
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

SRS - Gestionnaire de packages

2017-03-13T13:47:39Z

Germain.Lecorps: /* Frontend */

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

[[Projet 2017 : Gestionnaire de packages Polytech| '''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.

== Cas d'utilisations ==

//TODO

//Nécessite de mettre au point l'IHM

== 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 [[Conception - Gestionnaire de packages| '''ici''']].

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

En haut de la page, un tutoriel explique aux utilisateurs comment utiliser le repository sur linux, c'est à dire à le rajouter dans les sources de packages, puis à installer les packages avec les commandes "sudo apt-get install ...".

Le reste de la page correspond à la liste des packages disponibles sur le repository, ainsi que des options de filtre pour restreindre la liste à certaines filières, matières, etc.

=== Dépôt d'une contribution ===
Cette page consiste en un formulaire à remplir pour proposer une contribution.

En haut de la page, un tutoriel explique aux utilisateurs ce qu'ils doivent saisir dans chacun des champs du formulaire, ainsi que les différents types de dépôts gérés par le système.

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 ===
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)

== 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).

= Réalisations =
== Frontend ==

* Visualisation des packages :
** L'affichage des packages à partir de la base de données est fonctionnelle.
** Les différents filtres pour trier les packages sont fonctionnels.

* Visualisation des tickets :
** Fonctionnement similaire à la visualisation des packages. Les fonctionnalités disponibles sont les mêmes.
**

* Formulaire de dépôt d'un package :
** Le formulaire a les fonctionnalités qui étaient initialement prévues. Lorsqu'un package est déposé, il apparaît ensuite dans la liste des tickets en attente.

= 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
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

SRS - Gestionnaire de packages

2017-03-13T13:38:57Z

Germain.Lecorps:

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

[[Projet 2017 : Gestionnaire de packages Polytech| '''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.

== Cas d'utilisations ==

//TODO

//Nécessite de mettre au point l'IHM

== 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 [[Conception - Gestionnaire de packages| '''ici''']].

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

En haut de la page, un tutoriel explique aux utilisateurs comment utiliser le repository sur linux, c'est à dire à le rajouter dans les sources de packages, puis à installer les packages avec les commandes "sudo apt-get install ...".

Le reste de la page correspond à la liste des packages disponibles sur le repository, ainsi que des options de filtre pour restreindre la liste à certaines filières, matières, etc.

=== Dépôt d'une contribution ===
Cette page consiste en un formulaire à remplir pour proposer une contribution.

En haut de la page, un tutoriel explique aux utilisateurs ce qu'ils doivent saisir dans chacun des champs du formulaire, ainsi que les différents types de dépôts gérés par le système.

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 ===
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)

== 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).

= Réalisations =
== Frontend ==

= 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
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

Fiche de suivi - Gestionnaire de packages

2017-03-03T10:30:23Z

Germain.Lecorps: /* Mercredi 01 Mars */

Voici la Fiche de suivi du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Avancée du projet =
== Semaine 1 : 23/01 - 29/01 ==
=== Lundi 23 Janvier ===
Travail de groupe :
* Formation du groupe
* Réflexion sur le sujet avec M. Donsez
* Envoi d'un mail explicatif à M. Palix et M. Danjean pour prise de rendez-vous
* Premières réflexions sur une solution de gestion de package

=== Mardi 24 Janvier ===
Travail de groupe :
* Réponse aux enseignants
* Design de la structure de l'application
Rémi Gattaz, Germain Lecorps et Thibaut Nouguier :
* Travail sur la doc sur les repository Debian
Régis Ramel :
* Travail sur le Wiki

=== Mercredi 25 Janvier ===
Travail de groupe :
* Entretiens avec M. Palix et M. Danjean pour préciser les exigences du projet, discuter des différentes possibilités et de ce qu'il est possible / intéressant de faire.
* Formalisation des objectifs du projet.

=== Jeudi 26 Janvier ===
Travail de groupe :
* Première séance de MPI : Description du projet, définition des rôles, exercice de map minder
Rémi Gattaz et Thibaut Nouguier :
* POC de création de package et d'application d'un fix
Germain Lecorps:
* Travail sur le Wiki : SRS
Régis Ramel :
* Envoi de la définition du sujet aux enseignants
* Constitution d'une liste de mail des enseignants pour obtenir la liste des outils nécessaires en RICM
* Envoi de la demande de recensement des outils requis en RICM

== Semaine 2 : 30/01 - 05/02 ==
=== Lundi 30 Janvier ===
Travail de groupe :
* Choix des technologies : Debian + langage de script.

=== Mardi 31 Janvier ===
Travail de groupe :
* Discussion pour le choix des langages : Python et Shell.
* Conception de la structure détaillée de l'application

Thibaut Nouguier :
* Création d'un repository local avec des packages Debian basiques (Reprepro)
* Installation des paquets Debian depuis le repository local
* Sécurisation du repository via des clés RSA

Rémi Gattaz :
* Recherches sur Reprepro
* Utilisation de Reprepro dans un container docker (pour environnement de dev)
* Interview par les étudiants PEIP

Régis Ramel :
* Mise au propre de la structure de l'application
* Travail sur le Wiki : Conception de l'application
* Travail sur le SRS : Fonctionnement de l'application

Germain Lecorps :
* Préparation de l’environnement de développement Web

=== Mercredi 01 Février ===

Thibaut Nouguier :
* Recherches complémentaires sur l'utilisateion de reprepro
* Simulation d'un cas d'utilisation avec reprepro en utilisant des clés GPG (master key, signing key, encryption key)

Rémi Gattaz :
* Recherches sur Aptly
* Utilisation de Aptly dans un container docker (pour environnement de dev)

Régis Ramel :
* Travail sur la structure de l'application
* Travail sur le Wiki
* Installation de Netbeans pour HTML5/Javascript

Germain Lecorps :
* [[Maquette - Gestionnaire de packages| '''Maquettes''']] de l'interface Web

=== Jeudi 02 Février ===
Travail de groupe :
* Deuxième séance de MPI : Exercice de Brainstorming, exercice de pitch

Rémi Gattaz et Thibaut Nouguier :
* Définition des actions du Controleur et de l'API

Thibaut Nouguier :
* Travail sur la base de données MySQL

Rémi Gattaz :
* Définition des routes offerte par l'API du contrôleur dans le backend - [[Conception - Gestionnaire de packages#API_offerte_par_le_contr.C3.B4leur | '''documentation''']]

Germain Lecorps :
* Formation Angular

=== Vendredi 03 Février ===
Rémi Gattaz et Thibaut Nouguier :
* Mise en place du scrum (définition des user stories et des tâches)

Rémi Gattaz :
* Ajout des user stories et des tâches dans le wiki
* Création du tableau scrum sur github

Germain Lecorps :
* Formation Angular.js

== Semaine 3 : 06/02 - 12/02 ==
=== Lundi 06 Février ===
Travail de groupe :
* Troisième séance de MPI : Matrice de risques et Coût du budget
* Revue de sprint, définition des objectifs du sprint 2

Rémi Gattaz :

Germain Lecorps :
* Travail sur le sprint Scrum
* Tutoriel Angular
* Formation Web
* Installation des outils
* Ébauche de site internet

Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur le wiki : (Fiche de Suivi, Scrum, MPI)
* Travail sur le sprint Scrum
* Création d'un nouveau projet Angular
* Push du projet Angular sur GitHub
* Travail sur un modèle de projet Angular (liens vers d'autres pages)

=== Mardi 07 Février ===
Thibaut Nouguier :
* Première version d'un Builder de package qui fonctionne pour :
** un ensemble de fichiers c avec un makefile
** un script

Rémi Gattaz :
* NetBeans Day
* Terminer composition environnement backend controller

Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web

=== Mercredi 08 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur l'interface Web : génération d'une FAQ
* Travail sur l'interface Web : amélioration de la page de login

Germain Lecorps :
* Formation Web
* Travail sur l'interface Web : Création du formulaire de Contribution

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller

=== Jeudi 09 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller (suite du travail de la veille)

Régis Ramel :
* Travail sur l'interface Web : dynamicité de l'affichage des liens
* Travail sur le Wiki

Germain Lecorps :
* Travail sur le Frontend

=== Vendredi 10 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Automatisation des tests du Backen-controller à chaque commit

Régis Ramel :
* Travail sur l'interface Web
* Travail sur la séance de MPI : calcul des coûts
* Travail sur la séance de MPI : préparation de la séance sur la communication interpersonelle

Germain Lecorps :
* Travail sur le FrontEnd

== Semaine 4 : 13/02 - 19/02 ==
=== Lundi 13 Février ===
Travail de groupe :
* Réunion pour définir les objectifs de la semaine en vue de la soutenance de mi-parcours

Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz :
* Travail sur notre modèle de modélisation des données (refonte de la BDD)
* Prise de rendez vous avec le Responsable du service informatique de Polytech

Régis Ramel :
* Travail sur le cout du projet : Main d'oeuvre, amortissement du matériel

Germain Lecorps :
* Travail sur le FrontEnd
* Formation sur le filtrage en angularjs

=== Mardi 14 Février ===
Travail de groupe :
* Quatrième séance de MPI : Communication interpersonnelles

Rémi Gattaz :
* Travail dans le controller backend
** Création des classes modèle Ticket, Package et Infos.
** Mise en place des routes /packages et /tickets
** Mise en place des liens dans le modèle
** Création du CRUD au travers de l'API REST sur les ressources Package et Ticket

Régis Ramel et Germain Lecorps :
* Travail sur la lecture des packages en Json

Thibaut Nouguier :
* Travail sur le Builder de package

=== Mercredi 15 Février ===
Rémi Gattaz et Régis Ramel :
* Rencontre avec M. Jean-Marc Palomares, responsable du CAS de l'UGA

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage sur la liste des packages
** Début de filtrage "complexe" sur ces packages

Rémi Gattaz :
* Découverte d'un problème avec mysql et waterline (absence de transaction)
* Remaniement de la BDD pour une migration de mysql vers mongodb
* Migration vers mongodb

Thibaut Nouguier :
* Travail sur le Builder de package

=== Jeudi 16 Février ===
Travail de groupe :
* Revue de sprint

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage "complexe" sur la liste des packages
** Ajout de la liste des tickets
** Modification de la lecture des Json pour suivre le nouveau

Rémi Gattaz :
* Fin de la migration vers mongo
* Complétion de l'API nécessaire à la complétion du Frontend

Thibaut Nouguier :
* Travail sur le Builder de package

=== Vendredi 17 Février ===
Travail de groupe :
* Soutenance de mi-parcours

Régis Ramel :
* Correction mineure sur l'interface Web

== Semaine 5 : 20/02 - 26/02 (Vacances) ==
=== Lundi 20 Février ===

=== Mardi 21 Février ===

=== Mercredi 22 Février ===
Rémi Gattaz :
* Ajout de l'appel tickets/:id/votes/results pour obtenir le score d'un ticket (upvotes, downvotes, neutres)
* Ajout de tests du modèle

=== Jeudi 23 Février ===
Rémi Gattaz :
* Completion des tests du model du Backend-controller

=== Vendredi 24 Février ===
Rémi Gattaz :
* Construction automatique de l'image docker du Backend-controller
* Mise à jour du projet Backend-controller-env pour utiliser cette image
* Mise en place de la création de la base Mongo à la création du container (utilisation de variables d'environnement)

=== Samedi 25 Février ===
Rémi Gattaz :
* Test de l'écriture de la documentation avec Swagger
* Début de l'écriture de la documentation avec API Blueprint

== Semaine 6 : 27/02 - 05/03 ==
=== Lundi 27 Février ===
Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web : Préparation de l'intégration de l'API

Régis Ramel :
* Travail sur le lancement de l'image docker du Backend-Controller-env

Rémi Gattaz :
* Documentation de l'API
* Tentative de résolution d'un problème de synchronisation dans l'API (une fonction asynchrone devait être appelée depuis une fonction synchrone du framework qui a été surchargée)

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly

=== Mardi 28 Février ===
Rémi Gattaz :
* Résolution du problème de la veille
* Fin de l'écriture de la documentation
* Validation de la version 1.0 de l'API

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly
* Renseignement sur chroot pour le builder

Régis Ramel :
* Lancement de l'image Docker du Backend-Controller-env
* Travail sur le lancement de l'API en local pour intégrer au FrontEnd
* Début d'intégration de l'API au FrontEnd

Germain Lecorps :
* Réinstallation de l’environnement suite à un bug inconnu

=== Mercredi 01 Mars ===

Thibaut Nouguier :
* Travail sur le builder de package

Régis Ramel & Germain Lecorps :
* Travail sur l'intégration de l'API

=== Jeudi 02 Mars ===

Thibaut Nouguier :
* Test du builder avec des scripts comme sources
* Packaging de Procesim pour les RICM3
* Correction de plusieurs erreurs du builder

=== Vendredi 03 Mars ===

Thibaut Nouguier :
* Travail sur le builder de package
* Test du builder avec un projet maven

== Semaine 7 : 06/03 - 12/03 ==
=== Lundi 06 Mars ===

=== Mardi 07 Mars ===

=== Mercredi 08 Mars ===

=== Jeudi 09 Mars ===

=== Vendredi 10 Mars ===

== Semaine 8 : 13/03 - 19/03 ==
=== Lundi 13 Mars ===

=== Mardi 14 Mars ===

=== Mercredi 15 Mars ===

=== Jeudi 16 Mars ===

=== Vendredi 17 Mars ===

Fiche de suivi - Gestionnaire de packages

2017-03-01T14:32:49Z

Germain.Lecorps: /* Mardi 28 Février */

Voici la Fiche de suivi du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Avancée du projet =
== Semaine 1 : 23/01 - 29/01 ==
=== Lundi 23 Janvier ===
Travail de groupe :
* Formation du groupe
* Réflexion sur le sujet avec M. Donsez
* Envoi d'un mail explicatif à M. Palix et M. Danjean pour prise de rendez-vous
* Premières réflexions sur une solution de gestion de package

=== Mardi 24 Janvier ===
Travail de groupe :
* Réponse aux enseignants
* Design de la structure de l'application
Rémi Gattaz, Germain Lecorps et Thibaut Nouguier :
* Travail sur la doc sur les repository Debian
Régis Ramel :
* Travail sur le Wiki

=== Mercredi 25 Janvier ===
Travail de groupe :
* Entretiens avec M. Palix et M. Danjean pour préciser les exigences du projet, discuter des différentes possibilités et de ce qu'il est possible / intéressant de faire.
* Formalisation des objectifs du projet.

=== Jeudi 26 Janvier ===
Travail de groupe :
* Première séance de MPI : Description du projet, définition des rôles, exercice de map minder
Rémi Gattaz et Thibaut Nouguier :
* POC de création de package et d'application d'un fix
Germain Lecorps:
* Travail sur le Wiki : SRS
Régis Ramel :
* Envoi de la définition du sujet aux enseignants
* Constitution d'une liste de mail des enseignants pour obtenir la liste des outils nécessaires en RICM
* Envoi de la demande de recensement des outils requis en RICM

== Semaine 2 : 30/01 - 05/02 ==
=== Lundi 30 Janvier ===
Travail de groupe :
* Choix des technologies : Debian + langage de script.

=== Mardi 31 Janvier ===
Travail de groupe :
* Discussion pour le choix des langages : Python et Shell.
* Conception de la structure détaillée de l'application

Thibaut Nouguier :
* Création d'un repository local avec des packages Debian basiques (Reprepro)
* Installation des paquets Debian depuis le repository local
* Sécurisation du repository via des clés RSA

Rémi Gattaz :
* Recherches sur Reprepro
* Utilisation de Reprepro dans un container docker (pour environnement de dev)
* Interview par les étudiants PEIP

Régis Ramel :
* Mise au propre de la structure de l'application
* Travail sur le Wiki : Conception de l'application
* Travail sur le SRS : Fonctionnement de l'application

Germain Lecorps :
* Préparation de l’environnement de développement Web

=== Mercredi 01 Février ===

Thibaut Nouguier :
* Recherches complémentaires sur l'utilisateion de reprepro
* Simulation d'un cas d'utilisation avec reprepro en utilisant des clés GPG (master key, signing key, encryption key)

Rémi Gattaz :
* Recherches sur Aptly
* Utilisation de Aptly dans un container docker (pour environnement de dev)

Régis Ramel :
* Travail sur la structure de l'application
* Travail sur le Wiki
* Installation de Netbeans pour HTML5/Javascript

Germain Lecorps :
* [[Maquette - Gestionnaire de packages| '''Maquettes''']] de l'interface Web

=== Jeudi 02 Février ===
Travail de groupe :
* Deuxième séance de MPI : Exercice de Brainstorming, exercice de pitch

Rémi Gattaz et Thibaut Nouguier :
* Définition des actions du Controleur et de l'API

Thibaut Nouguier :
* Travail sur la base de données MySQL

Rémi Gattaz :
* Définition des routes offerte par l'API du contrôleur dans le backend - [[Conception - Gestionnaire de packages#API_offerte_par_le_contr.C3.B4leur | '''documentation''']]

Germain Lecorps :
* Formation Angular

=== Vendredi 03 Février ===
Rémi Gattaz et Thibaut Nouguier :
* Mise en place du scrum (définition des user stories et des tâches)

Rémi Gattaz :
* Ajout des user stories et des tâches dans le wiki
* Création du tableau scrum sur github

Germain Lecorps :
* Formation Angular.js

== Semaine 3 : 06/02 - 12/02 ==
=== Lundi 06 Février ===
Travail de groupe :
* Troisième séance de MPI : Matrice de risques et Coût du budget
* Revue de sprint, définition des objectifs du sprint 2

Rémi Gattaz :

Germain Lecorps :
* Travail sur le sprint Scrum
* Tutoriel Angular
* Formation Web
* Installation des outils
* Ébauche de site internet

Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur le wiki : (Fiche de Suivi, Scrum, MPI)
* Travail sur le sprint Scrum
* Création d'un nouveau projet Angular
* Push du projet Angular sur GitHub
* Travail sur un modèle de projet Angular (liens vers d'autres pages)

=== Mardi 07 Février ===
Thibaut Nouguier :
* Première version d'un Builder de package qui fonctionne pour :
** un ensemble de fichiers c avec un makefile
** un script

Rémi Gattaz :
* NetBeans Day
* Terminer composition environnement backend controller

Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web

=== Mercredi 08 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur l'interface Web : génération d'une FAQ
* Travail sur l'interface Web : amélioration de la page de login

Germain Lecorps :
* Formation Web
* Travail sur l'interface Web : Création du formulaire de Contribution

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller

=== Jeudi 09 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller (suite du travail de la veille)

Régis Ramel :
* Travail sur l'interface Web : dynamicité de l'affichage des liens
* Travail sur le Wiki

Germain Lecorps :
* Travail sur le Frontend

=== Vendredi 10 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Automatisation des tests du Backen-controller à chaque commit

Régis Ramel :
* Travail sur l'interface Web
* Travail sur la séance de MPI : calcul des coûts
* Travail sur la séance de MPI : préparation de la séance sur la communication interpersonelle

Germain Lecorps :
* Travail sur le FrontEnd

== Semaine 4 : 13/02 - 19/02 ==
=== Lundi 13 Février ===
Travail de groupe :
* Réunion pour définir les objectifs de la semaine en vue de la soutenance de mi-parcours

Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz :
* Travail sur notre modèle de modélisation des données (refonte de la BDD)
* Prise de rendez vous avec le Responsable du service informatique de Polytech

Régis Ramel :
* Travail sur le cout du projet : Main d'oeuvre, amortissement du matériel

Germain Lecorps :
* Travail sur le FrontEnd
* Formation sur le filtrage en angularjs

=== Mardi 14 Février ===
Travail de groupe :
* Quatrième séance de MPI : Communication interpersonnelles

Rémi Gattaz :
* Travail dans le controller backend
** Création des classes modèle Ticket, Package et Infos.
** Mise en place des routes /packages et /tickets
** Mise en place des liens dans le modèle
** Création du CRUD au travers de l'API REST sur les ressources Package et Ticket

Régis Ramel et Germain Lecorps :
* Travail sur la lecture des packages en Json

Thibaut Nouguier :
* Travail sur le Builder de package

=== Mercredi 15 Février ===
Rémi Gattaz et Régis Ramel :
* Rencontre avec M. Jean-Marc Palomares, responsable du CAS de l'UGA

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage sur la liste des packages
** Début de filtrage "complexe" sur ces packages

Rémi Gattaz :
* Découverte d'un problème avec mysql et waterline (absence de transaction)
* Remaniement de la BDD pour une migration de mysql vers mongodb
* Migration vers mongodb

Thibaut Nouguier :
* Travail sur le Builder de package

=== Jeudi 16 Février ===
Travail de groupe :
* Revue de sprint

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage "complexe" sur la liste des packages
** Ajout de la liste des tickets
** Modification de la lecture des Json pour suivre le nouveau

Rémi Gattaz :
* Fin de la migration vers mongo
* Complétion de l'API nécessaire à la complétion du Frontend

Thibaut Nouguier :
* Travail sur le Builder de package

=== Vendredi 17 Février ===
Travail de groupe :
* Soutenance de mi-parcours

Régis Ramel :
* Correction mineure sur l'interface Web

== Semaine 5 : 20/02 - 26/02 (Vacances) ==
=== Lundi 20 Février ===

=== Mardi 21 Février ===

=== Mercredi 22 Février ===
Rémi Gattaz :
* Ajout de l'appel tickets/:id/votes/results pour obtenir le score d'un ticket (upvotes, downvotes, neutres)
* Ajout de tests du modèle

=== Jeudi 23 Février ===
Rémi Gattaz :
* Completion des tests du model du Backend-controller

=== Vendredi 24 Février ===
Rémi Gattaz :
* Construction automatique de l'image docker du Backend-controller
* Mise à jour du projet Backend-controller-env pour utiliser cette image
* Mise en place de la création de la base Mongo à la création du container (utilisation de variables d'environnement)

=== Samedi 25 Février ===
Rémi Gattaz :
* Test de l'écriture de la documentation avec Swagger
* Début de l'écriture de la documentation avec API Blueprint

== Semaine 6 : 27/02 - 05/03 ==
=== Lundi 27 Février ===
Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web : Préparation de l'intégration de l'API

Régis Ramel :
* Travail sur le lancement de l'image docker du Backend-Controller-env

Rémi Gattaz :
* Documentation de l'API
* Tentative de résolution d'un problème de synchronisation dans l'API (une fonction asynchrone devait être appelée depuis une fonction synchrone du framework qui a été surchargée)

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly

=== Mardi 28 Février ===
Rémi Gattaz :
* Résolution du problème de la veille
* Fin de l'écriture de la documentation
* Validation de la version 1.0 de l'API

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly
* Renseignement sur chroot pour le builder

Régis Ramel :
* Lancement de l'image Docker du Backend-Controller-env
* Travail sur le lancement de l'API en local pour intégrer au FrontEnd
* Début d'intégration de l'API au FrontEnd

Germain Lecorps :
* Réinstallation de l’environnement suite à un bug inconnu

=== Mercredi 01 Mars ===

=== Jeudi 02 Mars ===

=== Vendredi 03 Mars ===

== Semaine 7 : 06/03 - 12/03 ==
=== Lundi 06 Mars ===

=== Mardi 07 Mars ===

=== Mercredi 08 Mars ===

=== Jeudi 09 Mars ===

=== Vendredi 10 Mars ===

== Semaine 8 : 13/03 - 19/03 ==
=== Lundi 13 Mars ===

=== Mardi 14 Mars ===

=== Mercredi 15 Mars ===

=== Jeudi 16 Mars ===

=== Vendredi 17 Mars ===

Fiche de suivi - Gestionnaire de packages

2017-02-16T09:27:08Z

Germain.Lecorps: /* Mardi 14 février */

Fiche de suivi - Gestionnaire de packages

2017-02-16T09:25:58Z

Germain.Lecorps: /* Lundi 13 février */

Fiche de suivi - Gestionnaire de packages

2017-02-16T09:25:11Z

Germain.Lecorps: /* Vendredi 10 février */

Fiche de suivi - Gestionnaire de packages

2017-02-16T09:24:47Z

Germain.Lecorps: /* Jeudi 09 février */

Liens - Gestionnaire de packages

2017-02-13T09:16:05Z

Germain.Lecorps: /* Liens utiles */

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Liens utiles =
[[Linux Packages| '''Packages Linux pour Polytech''']]

Debian Policy Manual :
* https://www.debian.org/doc/debian-policy/index.html#contents
* https://www.debian.org/doc/debian-policy/ch-controlfields.html
* https://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg

Debian Repositories :
* [https://wiki.debian.org/HowToSetupADebianRepository '''List of Debian repository servers''']
** [https://wiki.debian-fr.xyz/Reprepro '''Reprepo'''] : [https://hub.docker.com/r/bbinet/reprepro/ '''Docker container''']
** [https://www.aptly.info/ '''Aptly'''] : [https://hub.docker.com/r/bryanhong/aptly/ '''Docker container''']

Building .deb :
* [https://wiki.debian.org/BuildingTutorial#Requirements '''Tutorial Debian : Building .deb''']
* [https://xan-manning.co.uk/making-deb-packages-using-docker/ '''Making .deb packages using Docker''']
* [https://blog.codeship.com/using-docker-build-debian-packages/ '''Using Docker to Build Debian Packages''']

Testing AngularJS :
* [https://docs.angularjs.org/guide/unit-testing '''Tutorial Test : AngularJS''']

Fiche de suivi - Gestionnaire de packages

2017-02-09T10:33:28Z

Germain.Lecorps: /* Mercredi 08 février */

Fiche de suivi - Gestionnaire de packages

2017-02-07T14:23:54Z

Germain.Lecorps: /* Lundi 06 février */

Scrum - Gestionnaire de packages

2017-02-06T09:16:11Z

Germain.Lecorps: /* 2eme Sprint : 06/01 - 19/02 */

Voici la Fiche de sprint Scrum du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= User Stories et Tâches =

== User stories ==
* UU1 : En tant qu'utilisateur, je veux me connecter afin d'utiliser l'application
* UU2 : En tant qu'utilisateur, je veux pouvoir visualiser la liste des packages afin de rechercher un package
* UU3 : En tant qu'utilisateur, je veux pouvoir créer un ticket afin de demander l'ajout d'un package
* UU4 : En tant qu'utilisateur, je veux pouvoir modifier un ticket que j'ai créé afin de modifier ma demande
* UU5 : En tant qu'utilisateur, je veux pouvoir créer un vote sur un ticket afin de montrer mon interêt à l'ajout d'un package
* UU6 : En tant qu'utilisateur, je veux pouvoir modifier/supprimer un vote sur un ticket afin de changer mon avis
* UA1 : En tant qu'administrateur, je veux pouvoir créer un package à partir d'un ticket afin d'ajouter un package sur le repository
* UA2 : En tant qu'administrateur, je veux pouvoir modifier/supprimer un package afin de retirer un package du repository
* UA3 : En tant qu'administrateur, je veux pouvoir modifier le statut d'un ticket afin de caractériser la demande
* UA4 : En tant qu'administrateur, je veux pouvoir ajouter/supprimer un administrateur à l'application afin de modifier les utilisateurs capable d'administrer l'application
* UA5 : En tant qu'administrateur, je veux pouvoir forcer la mise à jour d'un package afin de lancer un build de façon immédiate
* UA6 : En tant qu'administrateur, je veux pouvoir visualiser les résultats des builds d'un package
* US1 : En tant que super administrateur, je veux pouvoir ajouter/supprimer un super administrateur à l'application pour autoriser un autre utilisateur à créer des packages
* US2 : En tant que super administrateur, je veux pouvoir gérer les droits d'accès au repository pour gérer les accès privé au repository

La nomenclature utilisé pour les identifiants des user stories est la suivante :
* UU : User story Utilisateur
* UA : User story Administrateur
* US : User story Super administrateur

== Taches ==
{| class="wikitable alternance center"
|+ Tâches
|-
! scope="col" width="5%" | Identifiant
! scope="col" | Description
! scope="col" width="5%" | Temps
(en 1/2j)
! scope="col" width="5%" | Priorité
(/10)
! scope="col" width="5%" | Dépendance
! scope="col" width="8%" | User Story
|-
| TFR1
| Connecter notre application au CAS de l'université
|
|
|
| UU1
|-
| TFR2
| Créer la vue packages
|
|
|
| UU2
|-
| TFR3
| Créer la vue administrateur des packages
|
|
|
| UA2
|-
| TFR4
| Créer la vue tickets
|
|
|
| UU3, UU4, UU5, UU6
|-
| TFR5
| Créer la vue administrateur des tickets
|
|
|
| UA1, UA3
|-
| TFR6
| Créer la vue administrateur des tickets
|
|
|
| UA5, UA6
|-
| TBB1
| Création d'un package à partir d'un dépôt git
|
|
|
| UA1
|-
| TBB2
| Création de log des builds
|
|
|
| UA6
|-
| TBC1
| Connecter à le backend à une base de donnée mysql
|
|
|
| UU*, UA*, US*
|-
| TBC2
| Créer les appels /packages
|
|
|
| UU2, UA2
|-
| TBC3
| Mettre en place des filtres
|
|
|
| UU2
|-
| TBC4
| Créer les appels /tickets
|
|
|
| UU3, UU4, UA1, UA3
|-
| TBC5
| Créer les appels /tickets/:id/votes
|
|
|
| UU5, UU6
|-
| TBC6
| Gérer les appels /packages/:id/builds
|
|
|
| A5, A6
|-
| TBC7
| Gérer dans la CLI le statut des utilisateurs
|
|
|
| UA4, US1
|-
| TBR1
| Gérer les droits d'accès au repository
|
|
|
| US2
|-
| TEX1
| Formation Angular 2
|
|
|
|
|-
| TEX2
| Mise en place environnement de développement du backend
|
|
|
|
|-
| TEX3
| Mise en place environnement de développement du frontend
|
|
|
|
|-
| TEX4
| Mise en place de tests automatisés du backend
|
|
|
|
|-
| TEX5
| Mise en place de tests automatisés du frontend
|
|
|
|
|}

La nomenclature utilisé pour les identifiants des tâches est la suivante :
* TFR : Frontend
* TBC : Backend Controller
* TBB : Backend builder
* TBR : Backend Repository
* TEX : Extra

= Sprints Scrum =
Un scrum board est disponible sur l'organisation github que nous avons créé : [https://github.com/orgs/Packebian/projects/1 '''Scrumt board''']
== 1er Sprint : 23/01 - 05/02 ==
=== Objectif initial : ===
* Étudier la faisabilité du projet
* Rencontrer des enseignants compétents dans la gestion de packages debian
* Commencer à se documenter et à étudier des solutions pour la réalisation du projet
* Établir la structure de l'application
* Faire le choix des technologies à utiliser

=== Réalisation : ===
* Rencontre avec M. Palix et M. Danjean, enseignants compétents en packages Debian
* Formalisation du sujet
* Design de la structure de l'application
* Définition des User stories

=== Revue de sprint : ===

== 2eme Sprint : 06/02 - 19/02 ==
=== Objectif initial : ===

=== Réalisation : ===

=== Revue de sprint : ===

== 3eme Sprint : 20/02 - 05/03 ==
=== Objectif initial : ===

=== Réalisation : ===

=== Revue de sprint : ===

== 4eme Sprint : 06/02 - 17/03 ==
=== Objectif initial : ===

=== Réalisation : ===

=== Revue de sprint : ===

SRS - Gestionnaire de packages

2017-02-01T14:39:22Z

Germain.Lecorps: /* Glossaire */

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

[[Projet 2017 : Gestionnaire de packages Polytech| '''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.

== Cas d'utilisations ==

//TODO

//Nécessite de mettre au point l'IHM

== 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 [[Conception - Gestionnaire de packages| '''ici''']].

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

En haut de la page, un tutoriel explique aux utilisateurs comment utiliser le repository sur linux, c'est à dire à le rajouter dans les sources de packages, puis à installer les packages avec les commandes "sudo apt-get install ...".

Le reste de la page correspond à la liste des packages disponibles sur le repository, ainsi que des options de filtre pour restreindre la liste à certaines filières, matières, etc.

=== Dépôt d'une contribution ===
Cette page consiste en un formulaire à remplir pour proposer une contribution.

En haut de la page, un tutoriel explique aux utilisateurs ce qu'ils doivent saisir dans chacun des champs du formulaire, ainsi que les différents types de dépôts gérés par le système.

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 ===
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)

== 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 ==
Package :

Git :

Tarball :

FrontEnd :

BackEnd :

Repository :

Debian :

Identifiants AGALAN :

Maintainer :

== 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
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

SRS - Gestionnaire de packages

2017-02-01T14:38:06Z

Germain.Lecorps: /* Glossaire */

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

[[Projet 2017 : Gestionnaire de packages Polytech| '''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.

== Cas d'utilisations ==

//TODO

//Nécessite de mettre au point l'IHM

== 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 [[Conception - Gestionnaire de packages| '''ici''']].

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

En haut de la page, un tutoriel explique aux utilisateurs comment utiliser le repository sur linux, c'est à dire à le rajouter dans les sources de packages, puis à installer les packages avec les commandes "sudo apt-get install ...".

Le reste de la page correspond à la liste des packages disponibles sur le repository, ainsi que des options de filtre pour restreindre la liste à certaines filières, matières, etc.

=== Dépôt d'une contribution ===
Cette page consiste en un formulaire à remplir pour proposer une contribution.

En haut de la page, un tutoriel explique aux utilisateurs ce qu'ils doivent saisir dans chacun des champs du formulaire, ainsi que les différents types de dépôts gérés par le système.

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 ===
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)

== 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 ==
Package :

Git :

Tarball :

FrontEnd :

BackEnd :

Repository :

Debian :

Identifiants AGALAN :

Maintainer :

Builder :

== 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
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

SRS - Gestionnaire de packages

2017-02-01T14:37:17Z

Germain.Lecorps: /* Glossaire */

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

[[Projet 2017 : Gestionnaire de packages Polytech| '''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.

== Cas d'utilisations ==

//TODO

//Nécessite de mettre au point l'IHM

== 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 ==
La structure de l'application est disponible [[Conception - Gestionnaire de packages| '''ici''']].

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

En haut de la page, un tutoriel explique aux utilisateurs comment utiliser le repository sur linux, c'est à dire à le rajouter dans les sources de packages, puis à installer les packages avec les commandes "sudo apt-get install ...".

Le reste de la page correspond à la liste des packages disponibles sur le repository, ainsi que des options de filtre pour restreindre la liste à certaines filières, matières, etc.

=== Dépôt d'une contribution ===
Cette page consiste en un formulaire à remplir pour proposer une contribution.

En haut de la page, un tutoriel explique aux utilisateurs ce qu'ils doivent saisir dans chacun des champs du formulaire, ainsi que les différents types de dépôts gérés par le système.

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 ===
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)

== 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 ==
Package :

Git :

Tarball :

FrontEnd :

BackEnd :

Repository :

Debian :

Identifiants AGALAN :

Maintainer :

== 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
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

SRS - Gestionnaire de packages

2017-02-01T14:36:03Z

Germain.Lecorps: /* Glossaire */

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

[[Projet 2017 : Gestionnaire de packages Polytech| '''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.

== Cas d'utilisations ==

//TODO

//Nécessite de mettre au point l'IHM

== 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 =
== Schéma de l'application ==

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

En haut de la page, un tutoriel explique aux utilisateurs comment utiliser le repository sur linux, c'est à dire à le rajouter dans les sources de packages, puis à installer les packages avec les commandes "sudo apt-get install ...".

Le reste de la page correspond à la liste des packages disponibles sur le repository, ainsi que des options de filtre pour restreindre la liste à certaines filières, matières, etc.

=== Dépôt d'une contribution ===
Cette page consiste en un formulaire à remplir pour proposer une contribution.

En haut de la page, un tutoriel explique aux utilisateurs ce qu'ils doivent saisir dans chacun des champs du formulaire, ainsi que les différents types de dépôts gérés par le système.

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 ===
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)

== 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 ==
Package :

Git :

Tarball :

FrontEnd :

BackEnd :

Repository :

Debian :

== 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
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

SRS - Gestionnaire de packages

2017-02-01T14:35:14Z

Germain.Lecorps: /* Étudiant */

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

[[Projet 2017 : Gestionnaire de packages Polytech| '''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.

== Cas d'utilisations ==

//TODO

//Nécessite de mettre au point l'IHM

== 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 =
== Schéma de l'application ==

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

En haut de la page, un tutoriel explique aux utilisateurs comment utiliser le repository sur linux, c'est à dire à le rajouter dans les sources de packages, puis à installer les packages avec les commandes "sudo apt-get install ...".

Le reste de la page correspond à la liste des packages disponibles sur le repository, ainsi que des options de filtre pour restreindre la liste à certaines filières, matières, etc.

=== Dépôt d'une contribution ===
Cette page consiste en un formulaire à remplir pour proposer une contribution.

En haut de la page, un tutoriel explique aux utilisateurs ce qu'ils doivent saisir dans chacun des champs du formulaire, ainsi que les différents types de dépôts gérés par le système.

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 ===
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)

== 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 ==
Package :

Git :

Tarball :

FrontEnd :

BackEnd :

Repository :

== 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
* [http://www.cse.msu.edu/~chengb/RE-491/Papers/IEEE-SRS-practice.pdf IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998]

File:Page contribution.png

2017-02-01T10:25:17Z

Germain.Lecorps: Germain.Lecorps uploaded a new version of "File:Page contribution.png"

File:Page FAQ.png

2017-02-01T10:16:44Z

Germain.Lecorps:

File:Page contribution.png

2017-02-01T10:16:23Z

Germain.Lecorps:

File:Page recherche.png

2017-02-01T10:16:14Z

Germain.Lecorps:

File:Page acceuil - Login.png

2017-02-01T10:15:44Z

Germain.Lecorps:

Maquette - Gestionnaire de packages

2017-02-01T10:15:27Z

Germain.Lecorps: Created page with "= Équipe = * Rémi Gattaz * Germain Lecorps (Chef de Projet) * Thibaut Nouguier * Régis Ramel (Scrum Master) == Gestionnaire de packages == === Identification === [[File:P..."

Projet 2017 : Gestionnaire de packages Polytech

2017-02-01T10:11:39Z

Germain.Lecorps: /* Documentation */

[[Projets_2016-2017| '''Lien vers la page des projets RICM5''']]

= Objectif du projet =
Durant les 3 années de RICM, de nombreux logiciels et bibliothèques d'outils sont utilisés pour des TP et des projets. Beaucoup de temps est passé durant les séances de TP à installer tous ces outils sur les machines des étudiants. Pour résoudre ce problème, nous avons voulu travailler sur une solution permettant aux étudiants d'installer tous ces outils plus rapidement.

Le but de notre projet est d'établir un catalogue des outils nécessaires au cursus RICM, et de mettre à disposition des outils pour les enseignants pour qu'il puissent proposer eux mêmes des packages à installer.
Pour réaliser cela, nous avons décidé de créer un gestionnaire de package qui permet d'uniformiser l'installation des outils proposés par les enseignants, grâce à la création de packages Debian facilement déployables sur les machines Linux des étudiants.

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Documentation =
* [[SRS - Gestionnaire de packages| '''SRS''']]
* [[Fiche de suivi - Gestionnaire de packages| '''Fiche de suivi''']]
* [[Scrum - Gestionnaire de packages| '''Scrum''']]
* [[Conception - Gestionnaire de packages| '''Conception''']]
* [[Maquette - Gestionnaire de packages| '''Maquette''']]
* [[Analyse des besoins - Gestionnaire de packages| '''Analyse des besoins''']]
* [[Media:PresentationDuProjet.pdf| '''Présentation du projet - Première séance de MPI''']]
* [[Media:PackagesPresentationConception.pdf|'''Présentation intermédiaire''']]
* [[Media:PackagesPresentationFinale.pdf| '''Présentation finale''']]

= Liens du projet =
* [https://github.com/'''Dépôt Git''']
* [[Liens - Gestionnaire de packages| '''Liens utiles''']]

Fiche de suivi - Gestionnaire de packages

2017-01-31T15:57:09Z

Germain.Lecorps: /* Mardi 31 janvier */

Fiche de suivi - Gestionnaire de packages

2017-01-31T15:56:32Z

Germain.Lecorps: /* Mardi 31 janvier */

Fiche de suivi - Gestionnaire de packages

2017-01-31T13:02:49Z

Germain.Lecorps: /* Mardi 31 janvier */

Linux Packages

2017-01-26T15:32:10Z

Germain.Lecorps: /* Probabilités et simulation */

Cette page recense les logiciels et les paquets nécessaires pour les cours à Polytech. Vous pouvez les installer selon vos besoins à l'issu de la [[Linux Install Party]]. N'hésitez pas à signaler les manques et les erreurs sur cette page. Précisez bien à chaque fois votre distribution (Debian/Ubuntu)
'''ainsi que sa version'''.

Les noms de paquets sont à gauche des ":" avec les conventions suivantes :
* paquet : paquet valable pour Debian et Ubuntu, toutes versions (raisonnables)
* paquet/debian : paquet valable pour Debian
* paquet/debian/wheezy : paquet valable pour la distribution Debian Wheezy
* paquet/ubuntu : paquet valable pour Ubuntu
* ...
* XXX : le paquet n'existe pas, le logiciel doit être installé manuellement

Dans la mesure du possible, pour profiter d'une intégration maximale de vos
logiciels entre eux, des mises à jour, des corrections des sécurités, etc.,
préférez installer les logiciels à partir des paquets de votre distribution.
Évidemment, il y a des exceptions à cette règle : logiciel non packagé, besoin
impératif d'une version plus récentes que celle packagée, etc.

__TOC__

== Comment chercher des paquets ==

=== Recherche ===

Recherche de paquets par mots clés dans leur description

sudo apt-get update
apt-cache search ''motclé1 motclé2''

Recherche de paquets par nom de fichier

sudo apt-file update
apt-file search ''nom_de_fichier''

Visualisation de la description d'un paquet

apt-cache show ''nom_de_paquet''

=== Bibliothèques ===

Quand vous avez besoin d'une bibliothèque pour de la programmation,
c'est souvent du paquet dont le nom fini par '''-dev''' que vous avez besoin.

== Tâches génériques ==

* nautilus-open-terminal
* minicom

=== Environnement de travail ===

* task-
* task-french-kde-desktop
* task-xfce-desktop
* task-lxde-desktop

=== Programmation ===

==== Outils ====
* build-essential : les outils de base (gcc, make, etc.)
* g++ : compilateur C++
* git, gitk, git-gui, tig, git-extras : Outils collaboratifs de gestion de versions (distribué)
* subversion git-svn : Outils collaboratifs de gestion de versions (centralisé)
* kgdb, ddd, valgrind : Outils de déverminage

==== Documentation des appels systèmes et de la bibliothèque C ====
* manpages-dev: Documentation sur l'API C et les appels systèmes (Section 2 et 3)
* manpages-posix: Documentation sur les outils POSIX (Section 1)
* manpages-posix-dev: Documentation sur l'API POSIX (Section 3 et 7)
* manpages-fr-dev: Documentation pour les appels systèmes (en français)
* manpages-fr-extra: Documentation pour l'API POSIX (en français)

==== Éditeurs ====
* vim ou emacs : éditeur de programmes (indentation automatique, coloration syntaxique, etc.)
* joe, nano
* kate, geany, code::blocks
* eclipse, eclipse-cdt, eclipse-egit : Outils de développement

==== AOO (programmation object en Java) ====

* openjdk-9-sdk : Java Standard Development Kit version 1.9
* openjdk-9-doc : la documentation du JDK (peut aussi être consultée en ligne)

=== Réseau ===

* wireshark : Analyseur de trames réseaux

== Enseignements RICM ==

=== Mobilité, Multimédia et Données Ouvertes ===

* apache2 : Apache HTTP Server metapackage
* libapache2-mod-php5: server-side, HTML-embedded scripting language (Apache 2 module)
* php5-curl: CURL module for php5
* php5-cli: command-line interpreter for the php5 scripting language

=== AOO (programmation object en Java) ===

* javacc javacc-doc : un générateur de parser avec sa doc
* XXX : plugin éclipse pour javacc
* XXX : EUML2 si une version gratuite est sortie pour Éclipse

=== OCaml ===

* ocaml : Méta-package pour l'essentiel du développement OCaml
* ocaml-core : la base d'OCaml
* ocaml-native-compilers : compilateurs optimisés (code natif)
* ocaml-findlib : gestionnaire de bibliothèques
* camlp4 : Préprocesseur pour la programmation caml
* liblablgl-ocaml-dev : pour de développement d'applications graphiques
* tuareg-mode : un mode OCaml pour Emacs

=== Réseau ===

* libreadline-dev : une bibliothèque nécessaire pour :
* XXX : des outils maisons à retrouver [http://imag-moodle.e.ujf-grenoble.fr/mod/folder/view.php?id=3368 ici]
* [http://socklab.forge.imag.fr/socklab.html Socklab] : Outil pour les TP sur les sockets réseaux
* gns3 : Simulateur de réseaux

=== ALM1 ===

* XXX : des outils disponibles [http://imag-moodle.e.ujf-grenoble.fr/mod/folder/view.php?id=2105 ici]

=== Traitement du signal ===

* python : Python language
* XXX : [http://www.continuum.io/ Anaconda]. Suivre le guide [http://chamilo1.grenet.fr/ujf/main/course_description/?cidReq=FAMILIARISATIONAVECPYTHONSUITEANACON&id_session=0&gidReq=0 ici]

=== Probabilités et simulation ===

* r-base : Outil R d'analyse statistique
* RStudio : RStudio est un environnement de développement multiplateforme pour R, un langage de programmation utilisé pour le traitement de données et l’analyse statistique. Il est disponible sous la licence libre AGPLv3, ou bien sous une licence commerciale, soumise à un abonnement annuel.

== Enseignements 3I ==

* libx11-dev : bibliothèque de développement X11

== Enseignements TIS ==

=== APO ===

* Eclipse/Netbeans : Développement Java

=== Réseaux ===

* Voir la section [http://air.imag.fr/index.php/Linux_Packages#R.C3.A9seau réseaux en RICM].

=== Applications médicales ===

* [http://www.debian.org/devel/debian-med/ Debian Med] - Dans les packages med-* (med-tasks pour tout)

== Autres enseignements ==

* libasound2-dev

=== Sagemath ===

* sagemath
* qtcreator
* qt4-designer
* qt4-dev-tools
* python3-all-dev
* python3-pyqt4
* python3-numpy
* pyqt4-dev-tools
* python-qwt5-qt4
* python-matplotlib
* ipython3
* ipython3-notebook
* ipython3-qtconsole

SRS - Gestionnaire de packages

2017-01-26T14:56:57Z

Germain.Lecorps: /* Cas d'utilisations */

SRS - Gestionnaire de packages

2017-01-26T14:56:44Z

Germain.Lecorps: /* Cas d'utilisations */

SRS - Gestionnaire de packages

2017-01-26T14:55:05Z

Germain.Lecorps: /* Utilisateurs potentiels */

SRS - Gestionnaire de packages

2017-01-26T14:32:37Z

Germain.Lecorps: /* Fonctionnalités */

SRS - Gestionnaire de packages

2017-01-26T14:24:08Z

Germain.Lecorps: Created page with "Voici la fiche SRS du Projet 2017 : Gestionnaire de package. '''Page d'accueil du projet''' = Équipe = * Rémi Gattaz *..."

Fiche de suivi - Gestionnaire de packages

2017-01-25T13:25:40Z

Germain.Lecorps: /* Semaine 1 : 23/01 - 29/01 */

Projet 2017 : Gestionnaire de packages Polytech

2017-01-24T14:51:12Z

Germain.Lecorps: /* Équipe */

[[Projets_2016-2017| '''Lien vers la page des projets RICM5''']]

= Objectif du projet =
Durant les 3 années de RICM, de nombreux logiciels et bibliothèques d'outils sont utilisés pour des TP et des projets. Beaucoup de temps est passé durant les séances de TP à installer tous ces outils sur les machines des étudiants. Pour résoudre ce problème, nous avons voulu travailler sur une solution permettant aux étudiants d'installer tous ces outils plus rapidement.

Le but de notre projet est d'établir un catalogue des outils nécessaires au cursus RICM, et de mettre à disposition des outils pour les enseignants pour qu'il puissent proposer eux mêmes des packages à installer.
Pour réaliser cela, nous avons décidé de créer un gestionnaire de package qui permet d'uniformiser l'installation des outils proposés par les enseignants, grâce à la création de packages Debian facilement déployables sur les machines Linux des étudiants.

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Livrables =
* [[SRS - Gestionnaire de packages| '''SRS''']]
* [[Fiche de suivi - Gestionnaire de packages| '''Fiche de suivi''']]
* [[Scrum - Gestionnaire de packages| '''Scrum''']]
* [[Conception - Gestionnaire de packages| '''Conception''']]
* [[Analyse des besoins - Gestionnaire de packages| '''Analyse des besoins''']]
* [https://github.com/'''Dépôt Git''']
* [[Media:PackagesPresentationConception.pdf|'''Présentation intermédiaire''']]
* [[Media:PackagesPresentationFinale.pdf| '''Présentation finale''']]
* [[Liens - Gestionnaire de packages| '''Liens utiles''']]

Projet 2017 : Gestionnaire de packages Polytech

2017-01-24T14:50:48Z

Germain.Lecorps: /* Équipe */

[[Projets_2016-2017| '''Lien vers la page des projets RICM5''']]

= Objectif du projet =
Durant les 3 années de RICM, de nombreux logiciels et bibliothèques d'outils sont utilisés pour des TP et des projets. Beaucoup de temps est passé durant les séances de TP à installer tous ces outils sur les machines des étudiants. Pour résoudre ce problème, nous avons voulu travailler sur une solution permettant aux étudiants d'installer tous ces outils plus rapidement.

Le but de notre projet est d'établir un catalogue des outils nécessaires au cursus RICM, et de mettre à disposition des outils pour les enseignants pour qu'il puissent proposer eux mêmes des packages à installer.
Pour réaliser cela, nous avons décidé de créer un gestionnaire de package qui permet d'uniformiser l'installation des outils proposés par les enseignants, grâce à la création de packages Debian facilement déployables sur les machines Linux des étudiants.

= Équipe =
* Rémi Gattaz
* <span style="color: #FF0000;">Germain Lecorps (Chef de Projet)</span>
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Livrables =
* [[SRS - Gestionnaire de packages| '''SRS''']]
* [[Fiche de suivi - Gestionnaire de packages| '''Fiche de suivi''']]
* [[Scrum - Gestionnaire de packages| '''Scrum''']]
* [[Conception - Gestionnaire de packages| '''Conception''']]
* [[Analyse des besoins - Gestionnaire de packages| '''Analyse des besoins''']]
* [https://github.com/'''Dépôt Git''']
* [[Media:PackagesPresentationConception.pdf|'''Présentation intermédiaire''']]
* [[Media:PackagesPresentationFinale.pdf| '''Présentation finale''']]
* [[Liens - Gestionnaire de packages| '''Liens utiles''']]

Scrum - Coivoiturage taxi

2016-12-13T07:40:55Z

Germain.Lecorps: /* Quatrième sprint : 28/11 - 11/12 */

[[ECOM2016_Covoiturage| '''Page d'accueil du projet''']]

= Sprints Scrum =

== Premier sprint : 03/10 - 16/10 ==

==='''Objectif'''===
* Réaliser tous les livrables pour la conception du site
** Diagramme Relationnel - Base de Données
** Dossier de Conception Système
** Analyse des besoins
** SRS
** Modèle de tâches
** Maquette

=== '''Travail réalisé''' : ===

Mardi 04/10 :
* Création des modèles de tâches
* Création de l'IHM abstraite
* Création des premières maquettes
Jeudi 06/10 :
* Finalisation des modèles de tâches
* Créations des dernières maquettes importantes

Mardi 11/10 :
* Création du dossier le conception / travail sur les fonctionnalités utilisateur
* Réalisation de l'analyse des besoins utilisateur grâce au questionnaire
Jeudi 13/10 :
* Travail sur le SRS
* Design de l'architecture système
* Design de la base de données
* Préparation pour la soutenance conception

=== '''Revue de sprint''' ===

* Les livrables ont été rendus à temps
* Les maquettes doivent être révisés pour une version mobile du site

== Deuxième sprint : 31/10 - 13/11 ==

==='''Objectif'''===
* Créer une base de site internet
* Mettre en place des images docker de base ainsi que des metrics
* Début de mise en place des EJB

=== '''Travail réalisé''' : ===

Mardi 01/11 :
* Création d'une base de site internet à partir d'un template
* Mise en place des metrics pour notre site internet
Jeudi 03/11 :
* Mise en place d'images docker pour glassfish, grafana, influxDB, mySQL...

Mardi 08/11 :
* Début de mise en place des EJB et de la base de données
* Modification du template
Jeudi 13/10 :
* Prise en main de AngularJS et HAProxy

=== '''Revue de sprint''' ===

* Une première version du site internet a bien été mise en place et les metrics correspondants fonctionnent
* Un premier travail sur la base de donnée à bien été effectué

== Troisième sprint : 14/11 - 27/11 ==

==='''Objectif'''===
* Installer MySQL Cluster, HAProxy
* Mise en place de la gestion d'utilisateurs
* Affichage de trajets pas tirés de la base de données (tests)

=== '''Travail réalisé''' : ===

Mardi 15/11 :
* Installation de MySQL Cluster sur le cloud (migration sur Azur)
* Mise en place de la gestion utilisateur
** Création d'un compte
** Connexion à un compte

Mardi 22/11 :
* Possibilité d'afficher un trajet (pas depuis la base de données) sur une carte Google (Communication JSON)

=== '''Revue de sprint''' ===

== Quatrième sprint : 28/11 - 11/12 ==

==='''Objectif'''===

* Mettre en place complètement la connexion utilisateur sécurisée
* Corrections de bugs
* Finaliser les documents

=== '''Travail réalisé''' : ===

Mardi 29/11 :

* Finalisation de la mise en place de HAProxy
* Utilisation de cookies pour se connecter au bon serveur

Mardi 06/12 :

* Correction des dernières erreurs
* Finalisation des documents

=== '''Revue de sprint''' ===

* Les objectifs principaux ont été réalisés
* La terminaison SSL n'a pas été mise en place puisqu'elle empêchait les appels AJAX

Scrum - Coivoiturage taxi

2016-12-13T07:31:05Z

Germain.Lecorps: /* Quatrième sprint : 28/11 - 11/12 */

[[ECOM2016_Covoiturage| '''Page d'accueil du projet''']]

= Sprints Scrum =

== Premier sprint : 03/10 - 16/10 ==

==='''Objectif'''===
* Réaliser tous les livrables pour la conception du site
** Diagramme Relationnel - Base de Données
** Dossier de Conception Système
** Analyse des besoins
** SRS
** Modèle de tâches
** Maquette

=== '''Travail réalisé''' : ===

Mardi 04/10 :
* Création des modèles de tâches
* Création de l'IHM abstraite
* Création des premières maquettes
Jeudi 06/10 :
* Finalisation des modèles de tâches
* Créations des dernières maquettes importantes

Mardi 11/10 :
* Création du dossier le conception / travail sur les fonctionnalités utilisateur
* Réalisation de l'analyse des besoins utilisateur grâce au questionnaire
Jeudi 13/10 :
* Travail sur le SRS
* Design de l'architecture système
* Design de la base de données
* Préparation pour la soutenance conception

=== '''Revue de sprint''' ===

* Les livrables ont été rendus à temps
* Les maquettes doivent être révisés pour une version mobile du site

== Deuxième sprint : 31/10 - 13/11 ==

==='''Objectif'''===
* Créer une base de site internet
* Mettre en place des images docker de base ainsi que des metrics
* Début de mise en place des EJB

=== '''Travail réalisé''' : ===

Mardi 01/11 :
* Création d'une base de site internet à partir d'un template
* Mise en place des metrics pour notre site internet
Jeudi 03/11 :
* Mise en place d'images docker pour glassfish, grafana, influxDB, mySQL...

Mardi 08/11 :
* Début de mise en place des EJB et de la base de données
* Modification du template
Jeudi 13/10 :
* Prise en main de AngularJS et HAProxy

=== '''Revue de sprint''' ===

* Une première version du site internet a bien été mise en place et les metrics correspondants fonctionnent
* Un premier travail sur la base de donnée à bien été effectué

== Troisième sprint : 14/11 - 27/11 ==

==='''Objectif'''===
* Installer MySQL Cluster, HAProxy
* Mise en place de la gestion d'utilisateurs
* Affichage de trajets pas tirés de la base de données (tests)

=== '''Travail réalisé''' : ===

Mardi 15/11 :
* Installation de MySQL Cluster sur le cloud (migration sur Azur)
* Mise en place de la gestion utilisateur
** Création d'un compte
** Connexion à un compte

Mardi 22/11 :
* Possibilité d'afficher un trajet (pas depuis la base de données) sur une carte Google (Communication JSON)

=== '''Revue de sprint''' ===

== Quatrième sprint : 28/11 - 11/12 ==

==='''Objectif'''===

=== '''Travail réalisé''' : ===

Mardi 29/11 :

Mardi 06/12 :

=== '''Revue de sprint''' ===

ECOM2016 Covoiturage

2016-12-12T16:55:00Z

Germain.Lecorps: /* Livrables */

[[ECOM-RICM| '''Lien vers la page des projets ECOM-RICM''']]

= Objectif du projet =
Le but du projet est de réaliser un site de réservation de Taxi. La particularité de nos Taxis est que ce sont des voiture Autonome.
L'application permettra de réserver des trajets en individuel mais aussi en covoiturage.
Les voyages seul seront des voyages porte à porte disponible à n'importe quelle heure tandis que les voyages en covoiturage s'effectueront entre différents points de rendez-vous à des horaires précis.

= Équipe =
* LECORPS Germain (Chef de projet)
* VOUTAT Manuel
* MATHIEU Tanguy
* HALLAL Marwan (Scrum Master)
* FOUNAS Abdelaziz

= Livrables =
* [[Fiche de suivi - Coivoiturage_taxi| '''Fiche de suivi''']]
* [[Dossier de Conception Système - Coivoiturage_taxi| '''Dossier de Conception Système''']]
* [[Diagramme Relationnel - Base de Données| '''Diagramme Relationnel - Base de Données''']]
* [[Media:etudeeComG4.pdf| '''Analyse des besoins''']]
* [[Maquette - Coivoiturage_taxi| '''Maquette''']]
* [[SRS - Coivoiturage_taxi| '''SRS''']]
* [[Modèle de tâches - Coivoiturage_taxi| '''Modèle de tâches''']]
* [[Scrum - Coivoiturage_taxi| '''Scrum''']]
* [https://github.com/marwanh/ecomEJB '''Dépôt Git -- EJB''']
* [https://github.com/abdelazizFounas/ECOM_GlassfishApp '''Dépôt Git -- Website''']
* [https://github.com/abdelazizFounas/ECOM_Application '''Dépôt Git -- Génération EAR''']
* [http://ecom45743.cloudapp.net/AutomaticAuto '''Apllication en ligne''']
* [[Media:Presentation_conception_g4.pdf| '''Présentation de Conception''']]
* [[Présentation finale - Coivoiturage_taxi| '''Présentation finale''']]

Scrum - Coivoiturage taxi

2016-12-11T11:50:35Z

Germain.Lecorps: /* Travail réalisé : */

Fiche de suivi - Coivoiturage taxi

2016-12-11T11:46:44Z

Germain.Lecorps:

Voici la fiche de suivi du projet ECOM 2016-2017 : Coivoiturage taxi

[[ECOM2016_Covoiturage| '''Page d'accueil du projet''']]

= Avancée du projet =
== Semaine 1 : 12/09 - 18/09 ==
'''Travail réalisé :'''
* Création du groupe
* Création des pages wiki

== Semaine 2 : 19/09 - 25/09 ==
'''Travail réalisé :'''
* Début d'apprentissage de JavaEE
* Création du questionnaire de besoins utilisateurs

== Semaine 3 : 26/09 - 02/10 ==
'''Travail réalisé :'''

* Prise en main de glassfish (mise en place d'un serveur glassfish), de AWS et de docker (création d'une image simple)

== Semaine 4 : 03/10 - 09/10 ==

''Début du premier sprint scrum''

'''Travail réalisé :'''
* Conception
** Création des modèles de tâches
** Création de l'IHM abstraite
** Créations des maquettes

* Tutoriel EJB, Tutoriel Servlet/JSP/REST/WS/Filter/Docker

== Semaine 5 : 10/10 - 16/10 ==

'''Travail réalisé :'''
* Conception système
** Fonctionnalités du système
** Design de l'architecture système
* Création de la base de données associée à notre système
* Finalisation de l'analyse des besoins à partir du questionnaire
* Création du SRS
* Préparation pour la soutenance conception

''Fin du premier sprint scrum''

== Semaine 6 : 17/10 - 23/10 ==
'''Travail réalisé :'''
* Soutenance conception
* Révision des différents pointes évoqués par les enseignants durant la soutenance

== Semaine 7 : 24/10 - 30/10 ==
'''Travail réalisé :'''
* Installation de tous les outils nécessaires pour le projet
* Prise en main (via tutoriel principalement) de ces outils et des différentes technologies (AngularJS, Bootstrap, Jersey, EJB, Swagger, Metrics, Docker, HAProxy, Grafana, InfluxDB, MySQL)

== Semaine 8 : 31/10 - 06/11 ==

''Début du deuxième sprint Scrum''

'''Travail réalisé :'''
* Création d'une base de site internet à partir d'un template
* Mise en place d'images docker pour glassfish, grafana, influxDB, mySQL...
* Mise en place des metrics pour notre site internet

'''Tâches à effectuer identifiées :'''
* Mise en place des EJB et de la base de données
* Modification du template
* Mise en place de HAProxy

== Semaine 9 : 07/11 - 13/11 ==
'''Travail réalisé :'''
* Modification du template pour le site
* Mise en place des EJB
* Prise en main et début de mise en place de HAProxy
* Prise en main d'AngularJS

''Fin du deuxième sprint Scrum''

== Semaine 10 : 14/11 - 20/11 ==
'''Travail réalisé :'''
*

'''Problèmes rencontrés :'''
*

'''Tâches à effectuer identifiées :'''
*

== Semaine 11 : 21/11 - 27/11 ==
'''Travail réalisé :'''
*

'''Problèmes rencontrés :'''
*

'''Tâches à effectuer identifiées :'''
*

== Semaine 12 : 28/11 - 04/12 ==
'''Travail réalisé :'''
*

'''Problèmes rencontrés :'''
*

'''Tâches à effectuer identifiées :'''
*

== Semaine 13 : 05/12 - 11/12 ==
'''Travail réalisé :'''
*

'''Problèmes rencontrés :'''
*

'''Tâches à effectuer identifiées :'''
*

ECOM2016 Covoiturage

2016-12-10T14:05:29Z

Germain.Lecorps: /* Livrables */

[[ECOM-RICM| '''Lien vers la page des projets ECOM-RICM''']]

= Objectif du projet =
Le but du projet est de réaliser un site de réservation de Taxi. La particularité de nos Taxis est que ce sont des voiture Autonome.
L'application permettra de réserver des trajets en individuel mais aussi en covoiturage.
Les voyages seul seront des voyages porte à porte disponible à n'importe quelle heure tandis que les voyages en covoiturage s'effectueront entre différents points de rendez-vous à des horaires précis.

= Équipe =
* LECORPS Germain (Chef de projet)
* VOUTAT Manuel
* MATHIEU Tanguy
* HALLAL Marwan (Scrum Master)
* FOUNAS Abdelaziz

= Livrables =
* [[Fiche de suivi - Coivoiturage_taxi| '''Fiche de suivi''']]
* [[Dossier de Conception Système - Coivoiturage_taxi| '''Dossier de Conception Système''']]
* [[Diagramme Relationnel - Base de Données| '''Diagramme Relationnel - Base de Données''']]
* [[Media:etudeeComG4.pdf| '''Analyse des besoins''']]
* [[Maquette - Coivoiturage_taxi| '''Maquette''']]
* [[SRS - Coivoiturage_taxi| '''SRS''']]
* [[Modèle de tâches - Coivoiturage_taxi| '''Modèle de tâches''']]
* [[Scrum - Coivoiturage_taxi| '''Scrum''']]
* [https://github.com/marwanh/ecomEJB '''Dépôt Git -- EJB''']
* [https://github.com/abdelazizFounas/ECOM_GlassfishApp '''Dépôt Git -- Website''']
* [https://github.com/abdelazizFounas/ECOM_Application '''Dépôt Git -- Génération EAR''']
* [http://52.174.55.174:8080/AutomaticAuto/ '''Apllication en ligne''']
* [[Media:Presentation_conception_g4.pdf| '''Présentation de Conception''']]
* [[Présentation finale - Coivoiturage_taxi| '''Présentation finale''']]

ECOM2016 Covoiturage

2016-12-10T14:03:28Z

Germain.Lecorps: /* Livrables */

[[ECOM-RICM| '''Lien vers la page des projets ECOM-RICM''']]

= Objectif du projet =
Le but du projet est de réaliser un site de réservation de Taxi. La particularité de nos Taxis est que ce sont des voiture Autonome.
L'application permettra de réserver des trajets en individuel mais aussi en covoiturage.
Les voyages seul seront des voyages porte à porte disponible à n'importe quelle heure tandis que les voyages en covoiturage s'effectueront entre différents points de rendez-vous à des horaires précis.

= Équipe =
* LECORPS Germain (Chef de projet)
* VOUTAT Manuel
* MATHIEU Tanguy
* HALLAL Marwan (Scrum Master)
* FOUNAS Abdelaziz

= Livrables =
* [[Fiche de suivi - Coivoiturage_taxi| '''Fiche de suivi''']]
* [[Dossier de Conception Système - Coivoiturage_taxi| '''Dossier de Conception Système''']]
* [[Diagramme Relationnel - Base de Données| '''Diagramme Relationnel - Base de Données''']]
* [[Media:etudeeComG4.pdf| '''Analyse des besoins''']]
* [[Maquette - Coivoiturage_taxi| '''Maquette''']]
* [[SRS - Coivoiturage_taxi| '''SRS''']]
* [[Modèle de tâches - Coivoiturage_taxi| '''Modèle de tâches''']]
* [[Scrum - Coivoiturage_taxi| '''Scrum''']]
* [https://github.com/marwanh/ecomEJB '''Dépôt Git -- EJB''']
* [https://github.com/abdelazizFounas/ECOM_GlassfishApp '''Dépôt Git -- Website''']
* [https://github.com/abdelazizFounas/ECOM_Application '''Dépôt Git -- Génération EAR''']
* [[Media:Presentation_conception_g4.pdf| '''Présentation de Conception''']]
* [[Présentation finale - Coivoiturage_taxi| '''Présentation finale''']]

ECOM2016 Covoiturage

2016-12-10T14:02:30Z

Germain.Lecorps: /* Livrables */

[[ECOM-RICM| '''Lien vers la page des projets ECOM-RICM''']]

= Objectif du projet =
Le but du projet est de réaliser un site de réservation de Taxi. La particularité de nos Taxis est que ce sont des voiture Autonome.
L'application permettra de réserver des trajets en individuel mais aussi en covoiturage.
Les voyages seul seront des voyages porte à porte disponible à n'importe quelle heure tandis que les voyages en covoiturage s'effectueront entre différents points de rendez-vous à des horaires précis.

= Équipe =
* LECORPS Germain (Chef de projet)
* VOUTAT Manuel
* MATHIEU Tanguy
* HALLAL Marwan (Scrum Master)
* FOUNAS Abdelaziz

= Livrables =
* [[Fiche de suivi - Coivoiturage_taxi| '''Fiche de suivi''']]
* [[Dossier de Conception Système - Coivoiturage_taxi| '''Dossier de Conception Système''']]
* [[Diagramme Relationnel - Base de Données| '''Diagramme Relationnel - Base de Données''']]
* [[Media:etudeeComG4.pdf| '''Analyse des besoins''']]
* [[Maquette - Coivoiturage_taxi| '''Maquette''']]
* [[SRS - Coivoiturage_taxi| '''SRS''']]
* [[Modèle de tâches - Coivoiturage_taxi| '''Modèle de tâches''']]
* [[Scrum - Coivoiturage_taxi| '''Scrum''']]
* [https://github.com/marwanh/ecomEJB '''Dépôt Git -- EJB''']
* [https://github.com/abdelazizFounas/ECOM_GlassfishApp '''Dépôt Git -- Website''']
* [https://github.com/abdelazizFounas/ECOM_Application '''Dépôt Git -- Génération EAR''']
* [[http://52.174.55.174:8080/AutomaticAuto/| '''Application en ligne''']]
* [[Media:Presentation_conception_g4.pdf| '''Présentation de Conception''']]
* [[Présentation finale - Coivoiturage_taxi| '''Présentation finale''']]

ECOM2016 Covoiturage

2016-12-10T14:01:56Z

Germain.Lecorps: /* Livrables */

[[ECOM-RICM| '''Lien vers la page des projets ECOM-RICM''']]

= Objectif du projet =
Le but du projet est de réaliser un site de réservation de Taxi. La particularité de nos Taxis est que ce sont des voiture Autonome.
L'application permettra de réserver des trajets en individuel mais aussi en covoiturage.
Les voyages seul seront des voyages porte à porte disponible à n'importe quelle heure tandis que les voyages en covoiturage s'effectueront entre différents points de rendez-vous à des horaires précis.

= Équipe =
* LECORPS Germain (Chef de projet)
* VOUTAT Manuel
* MATHIEU Tanguy
* HALLAL Marwan (Scrum Master)
* FOUNAS Abdelaziz

= Livrables =
* [[Fiche de suivi - Coivoiturage_taxi| '''Fiche de suivi''']]
* [[Dossier de Conception Système - Coivoiturage_taxi| '''Dossier de Conception Système''']]
* [[Diagramme Relationnel - Base de Données| '''Diagramme Relationnel - Base de Données''']]
* [[Media:etudeeComG4.pdf| '''Analyse des besoins''']]
* [[Maquette - Coivoiturage_taxi| '''Maquette''']]
* [[SRS - Coivoiturage_taxi| '''SRS''']]
* [[Modèle de tâches - Coivoiturage_taxi| '''Modèle de tâches''']]
* [[Scrum - Coivoiturage_taxi| '''Scrum''']]
* [https://github.com/marwanh/ecomEJB '''Dépôt Git -- EJB''']
* [https://github.com/abdelazizFounas/ECOM_GlassfishApp '''Dépôt Git -- Website''']
* [https://github.com/abdelazizFounas/ECOM_Application '''Dépôt Git -- Génération EAR''']
* [[Application en ligne - Coivoiturage_taxi| '''Application en ligne''']]
* [[Media:Presentation_conception_g4.pdf| '''Présentation de Conception''']]
* [[Présentation finale - Coivoiturage_taxi| '''Présentation finale''']]

Scrum - Coivoiturage taxi

2016-12-06T09:48:23Z

Germain.Lecorps: /* Troisième sprint : 14/11 - 27/11 */

[[ECOM2016_Covoiturage| '''Page d'accueil du projet''']]

= Sprints Scrum =

== Premier sprint : 03/10 - 16/10 ==

==='''Objectif'''===
* Réaliser tous les livrables pour la conception du site
** Diagramme Relationnel - Base de Données
** Dossier de Conception Système
** Analyse des besoins
** SRS
** Modèle de tâches
** Maquette

=== '''Travail réalisé''' : ===

Mardi 04/10 :
* Création des modèles de tâches
* Création de l'IHM abstraite
* Création des premières maquettes
Jeudi 06/10 :
* Finalisation des modèles de tâches
* Créations des dernières maquettes importantes

Mardi 11/10 :
* Création du dossier le conception / travail sur les fonctionnalités utilisateur
* Réalisation de l'analyse des besoins utilisateur grâce au questionnaire
Jeudi 13/10 :
* Travail sur le SRS
* Design de l'architecture système
* Design de la base de données
* Préparation pour la soutenance conception

=== '''Revue de sprint''' ===

* Les livrables ont été rendus à temps
* Les maquettes doivent être révisés pour une version mobile du site

== Deuxième sprint : 31/10 - 13/11 ==

==='''Objectif'''===
* Créer une base de site internet
* Mettre en place des images docker de base ainsi que des metrics
* Début de mise en place des EJB

=== '''Travail réalisé''' : ===

Mardi 01/11 :
* Création d'une base de site internet à partir d'un template
* Mise en place des metrics pour notre site internet
Jeudi 03/11 :
* Mise en place d'images docker pour glassfish, grafana, influxDB, mySQL...

Mardi 08/11 :
* Début de mise en place des EJB et de la base de données
* Modification du template
Jeudi 13/10 :
* Prise en main de AngularJS et HAProxy

=== '''Revue de sprint''' ===

* Une première version du site internet a bien été mise en place et les metrics correspondants fonctionnent
* Un premier travail sur la base de donnée à bien été effectué

== Troisième sprint : 14/11 - 27/11 ==

==='''Objectif'''===
* Installer MySQL Cluster, HAProxy
* Mise en place de la gestion d'utilisateurs
* Affichage de trajets pas tirés de la base de données (tests)

=== '''Travail réalisé''' : ===

Mardi 15/11 :
* Installation de MySQL Cluster sur le cloud (migration sur Azur)
* Mise en place de la gestion utilisateur
** Création d'un compte
** Connexion à un compte

Mardi 22/11 :
* Possibilité d'afficher un trajet (pas depuis la base de données) sur une carte Google
* Réalisation de l'analyse des besoins utilisateur grâce au questionnaire

=== '''Revue de sprint''' ===

Scrum - Coivoiturage taxi

2016-12-06T09:48:12Z

Germain.Lecorps: /* Sprints Scrum */

[[ECOM2016_Covoiturage| '''Page d'accueil du projet''']]

= Sprints Scrum =

== Premier sprint : 03/10 - 16/10 ==

==='''Objectif'''===
* Réaliser tous les livrables pour la conception du site
** Diagramme Relationnel - Base de Données
** Dossier de Conception Système
** Analyse des besoins
** SRS
** Modèle de tâches
** Maquette

=== '''Travail réalisé''' : ===

Mardi 04/10 :
* Création des modèles de tâches
* Création de l'IHM abstraite
* Création des premières maquettes
Jeudi 06/10 :
* Finalisation des modèles de tâches
* Créations des dernières maquettes importantes

Mardi 11/10 :
* Création du dossier le conception / travail sur les fonctionnalités utilisateur
* Réalisation de l'analyse des besoins utilisateur grâce au questionnaire
Jeudi 13/10 :
* Travail sur le SRS
* Design de l'architecture système
* Design de la base de données
* Préparation pour la soutenance conception

=== '''Revue de sprint''' ===

* Les livrables ont été rendus à temps
* Les maquettes doivent être révisés pour une version mobile du site

== Deuxième sprint : 31/10 - 13/11 ==

==='''Objectif'''===
* Créer une base de site internet
* Mettre en place des images docker de base ainsi que des metrics
* Début de mise en place des EJB

=== '''Travail réalisé''' : ===

Mardi 01/11 :
* Création d'une base de site internet à partir d'un template
* Mise en place des metrics pour notre site internet
Jeudi 03/11 :
* Mise en place d'images docker pour glassfish, grafana, influxDB, mySQL...

Mardi 08/11 :
* Début de mise en place des EJB et de la base de données
* Modification du template
Jeudi 13/10 :
* Prise en main de AngularJS et HAProxy

=== '''Revue de sprint''' ===

* Une première version du site internet a bien été mise en place et les metrics correspondants fonctionnent
* Un premier travail sur la base de donnée à bien été effectué

== Troisième sprint : 14/11 - 27/11 ==

==='''Objectif'''===
* Installer MySQL Cluster, HAProxy
* Mise en place de la gestion d'utilisateurs
* Affichage de trajets pas tirés de la base de données (tests)

=== '''Travail réalisé''' : ===

Mardi 15/11 :
* Installation de MySQL Cluster sur le cloud (migration sur Azur)
* Mise en place de la gestion utilisateur
** Création d'un compte
** Connexion à un compte

Mardi 22/11 :
* Possibilité d'afficher un trajet (pas depuis la base de données) sur une carte Google
* Réalisation de l'analyse des besoins utilisateur grâce au questionnaire

=== '''Revue de sprint''' ===

* Les livrables ont été rendus à temps
* Les maquettes doivent être révisés pour une version mobile du site

Fiche de suivi - Coivoiturage taxi

2016-12-06T09:20:29Z

Germain.Lecorps: /* Semaine 9 : 07/11 - 13/11 */