Scrum - Gestionnaire de packages

From air
Jump to navigation Jump to search

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

Page d'accueil du projet

Équipe

  • Rémi Gattaz
  • Germain Lecorps (Chef de Projet)
  • Thibaut Nouguier
  • Régis Ramel (Scrum Master)

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

Tâches
Identifiant Description Temps

(en 1/2j)

Priorité

(/10)

Dépendance 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 builds 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éé : Scrum 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 :

Objectifs atteints :

  • La faisabilité du projet est établie
  • Le sujet a été défini précisément (voir SRS)
  • La structure de l'application a été définie (voir Conception)
  • Le choix des technologies a été fait (voir SRS)

Préparation des sprints suivants :

  • Établissement des User Stories
  • Établissement des tâches

2eme Sprint : 06/02 - 19/02

Objectif initial :

  • Établir une structure d'interface Web
  • Créer les premières fonctionnalités de l'API
  • Obtenir une première version de la création de package dans le composant Builder

Réalisation :

  • Frontend
    • Création de la structure du site
    • Création des pages
      • Login
      • Liste des packages
      • Liste des tickets
      • Contribution
      • FAQ / Tutoriels
    • Lecture dynamique des FAQ, tutos, packages et tickets à partir de fichiers Json
  • Backend Controller :
    • Mise en place des environnements de dev/tests/production
    • Construction de l'API nécessaire à la complétion du Frontend
  • Backend Builder :
    • Première version du Builder
    • Support basique de projet de type :
      • Makefile
      • Maven
      • Ant
      • Gradle
      • Exécutable
      • Python

Revue de sprint :

La structure du site est développée. La navigation entre les pages est opérationnelle, il est possible d'obtenir une liste des packages/tickets, et d'effectuer des fonctions de tri/filtre. De plus, la FAQ et les tutoriels sont générés à partir de fichiers Json.

L'API est suffisamment avancée pour permettre de lier au Frontend au Backend.

La première version du Builder permet de générer des packages Debian selon certaines conditions (Makefile, Maven, ...).

3eme Sprint : 20/02 - 05/03

Objectif initial :

Application :

  • Prévoir un déploiement de l'application

Frontend :

  • Intégrer les appels API au Frontend
  • Faire la section Administration (Gestion tickets + Résultats des builds)
  • Ajouter gestion des votes à la liste des tickets

Backend :

  • Controller
    • Régler la question du Login
    • Construction des infos pour le Builder
    • Commencer l'automatisation des mises à jour
    • Ecriture de la documentation de l'API
    • Mise en place de tests automatique de l'API (tests externes)
    • Mise en place de tests automatiques du modèle utilisé par l'API (tests internes)
  • Builder
    • Améliorer le Builder (support, adaptabilité)
  • Repository
    • Construction ou utilisation d'une image docker Aptly
    • Mettre en place un Repository

Réalisation :

Application :

  • Remise au propre de l'ensemble du code produit

Frontend :

  • Début de l'intégration de l'API
  • Ré-arrangement du javascript pour obtenir une structure de projet Angular

Backend :

  • Controller
    • Construction automatique d'une image docker (latest et stable)
    • Mise en place de tests automatiques du modèle utilisé par l'API (tests internes)
    • Mise en place de tests automatiques de l'API à partir de sa description (tests externes)
    • Lint de tous le code (opération de normalisation des sources)
  • Builder
    • Corrections d'erreurs
    • Optimisation de la construction de packages
    • Génération d'un docker file
  • Repository
    • Tous les composants du projet sont prêts à être packagés dans des images docker pour faciliter le déploiement

Revue de sprint :

Application :

Nous avons décidé que le but du projet est de laisser les outils et la documentation pour permettre à un prochain groupe de reprendre le projet. Pour la problématique de déploiement, nous allons donc créer des images docker pour l'ensemble des composants de l'application.

Frontend : Au niveau du Frontend, les premiers appels à l'API ont été intégrés (récupération de la liste des packages et des tickets). De plus, la structure du Frontend a été entièrement réorganisée pour correspondre à des modules Angular.

Backend : Les construction d'images docker sont maintenant automatiques. Des correctifs et des tests automatiques ont été appliqués sur l'API.

4eme Sprint : 06/03 - 17/03

Objectif initial :

Application :

  • Préparation du passage de relais du projet

Frontend :

  • Gestion du login
  • Intégration de quelques appels
    • Liste des packages
    • Liste des tickets
    • Gestion des votes
    • Création de tickets

Backend :

  • Controller
    • Gestion du login avec auth0 (prévoir que ce service puisse être remplacé facilement)
    • Meilleure gestion des clés étrangères par l'utilisation de services
  • Builder
    • Suite des tests (maven et gradle)
    • Ajouter de la modularité (notamment pour étendre le builder)
  • Repository
    • Tests de l'image Aptly

Réalisation :

Application :

  • Rédaction de documentation

Frontend :

  • Gestion du login via un token et une authentification Auth0
  • Les appels suivants sont fonctionnels :
    • Liste des packages
    • Liste des tickets
    • Gestion des votes (ajout/modification/suppression)
    • Création de tickets

Revue de sprint :