Dans ce chapitre, nous allons nous servir de GitLab comme outil de planification de nos développements. La méthodologie DevOps veut que la planification de tout le backlog de l'application et des fonctionnalités à développer soit effectuée en amont, et suivie tout au long de la chaîne de CI/CD.
Il est temps de définir notre premier backlog, c'est-à-dire l'ensemble des tâches à réaliser sur notre projet.
Créez votre projet GitLab
Dans un premier temps, nous allons créer un projet dans GitLab. Pour cela, nous allons utiliser la plateforme https://gitlab.com/, afin d'éviter d'installer notre propre plateforme GitLab en local.
Si vous n'avez pas encore de compte sur GitLab, je vous invite à vous en créer un, puis à vous connecter.
Une fois connecté, vous arrivez sur une page listant tous vos projets. Si vous venez de créer le compte, normalement cette page sera vide.
Comme expliqué dans le premier chapitre, nous allons nous baser sur le projet PetClinic tout au long du cours. Dans ce chapitre, nous allons commencer à planifier le développement de fonctionnalités pour ce projet.
Pour créer un nouveau projet dans GitLab, une fois connecté, cliquez sur le bouton New Project. Sur la nouvelle page, il faut entrer un nouveau nom de projet. Dans le champ Project Name, nous allons entrer le nom spring-petclinic-microservices. Notez au passage que GitLab remplit automatiquement le champ Project Slug. Il est impératif de passer le projet en Public afin de bénéficier de toutes les fonctionnalités abordées dans ce cours. Une fois tous les champs remplis, l'écran devrait ressembler à cela :
Appuyez maintenant sur le bouton Create Project. Vous arrivez alors sur la page du projet fraîchement créé. Avant de récupérer le code source de l'application, et de l'intégrer dans GitLab, nous allons mettre en place les différentes briques nécessaires au bon déroulement du projet. Tout d'abord, nous allons naviguer dans la partie Issues, afin d'ajouter les colonnes nécessaires à notre projet. Pour ce faire, il suffit d'aller sur le menu à gauche, survoler le menu Issues, et cliquer sur le lien Boards. Sur cette page, GitLab nous propose d'ajouter les listes par défaut via le bouton Add default lists. GitLab crée alors deux nouvelles colonnes, To Do et Doing :
Ce board sera notre board par défaut durant tout notre projet, afin de voir son avancement. Nous allons ensuite créer les différents labels que nous avons vus précédemment, afin de pouvoir créer et catégoriser les issues que nous allons ouvrir. Pour ce faire, nous allons aller dans le sous-menu Labels du menu Issues. Sur la nouvelle page, il faut alors cliquer sur le bouton New Label pour créer une nouvelle catégorie d'issue. Notez que GitLab a déjà créé les deux labels To Do et Doing pour nous.
Sur la page de création de nouveaux labels, nous allons ajouter tous les labels nécessaires à la catégorisation des issues :
Vous noterez la création de plusieurs labels que je n'ai pas détaillés : High, Medium, Low, Ready, Rejected et In Review. Ces labels sont utilisés pour catégoriser plusieurs issues et pour créer un nouveau board, que nous allons appeler Product Backlog. Pour ce faire, il faut retourner dans le menu Board. Tout d'abord, dans la page courante, cliquez sur Add List et sélectionnez le label In Review pour ajouter une nouvelle colonne dans le board courant. Le nouveau board doit ressembler à cela (pour des questions de lisibilité, j'ai replié les colonnes Open et Closed dans la capture d'écran suivante) :
Ensuite, sur la page, en haut à gauche, il y a une liste déroulante contenant tous les boards créés. Pour l'instant, il n'y en a qu'un seul, celui de développement qui est actuellement affiché.
Dans cette liste déroulante, sélectionnez Create New Board, puis donnez-lui le nom de Product. Ce board sera notre Product Backlog qui listera toutes les epics, ainsi que les user stories associées et leurs états respectifs :
Sur la nouvelle page, après avoir cliqué sur le bouton Create Board, il faut maintenant ajouter les colonnes Low, Medium, High et Rejected afin de pouvoir classifier les epics sur ce board. Pour ce faire, il faut cliquer sur la liste déroulante Add List, et ajouter les labels correspondants.
Votre board devrait ressembler maintenant à cela :
Nous avons maintenant tous les outils nécessaires afin de commencer notre travail sur le projet. Le workflow de développement se déroule comme suit :
Le product owner travaille avec les utilisateurs finaux afin de définir un Product Backlog. Ce Product Backlog est constitué de différentes epics.
Ces epics doivent faire apparaître plusieurs critères, comme par exemple des wireframes ou autres écrans définissant l'application. Une epic en high passe en sprint backlog lorsque son périmètre est délimité avec un label Ready, et le développement est confirmé avec le client. Ce n’est qu’à ce moment que l’epic est discutée avec l’équipe et décomposée en user stories, décrivant la feature à développer.
Les user stories doivent respecter la Definition of Ready définie plus tôt, lors du cycle de développement. Une user story n'est ready que si elle a bien été écrite, et contient tous les éléments nécessaires à son développement durant le sprint.
Une fois que le sprint backlog a été décomposé en user stories, nous pouvons alors commencer la planification du sprint backlog.
Pour ce cours, nous allons créer deux issues :
une epic ;
une user story.
Créez votre première epic
Pour créer une epic, le plus simple est d'aller dans le sous-menu List du menu Issues, et de cliquer sur le bouton New Issue.
Sur la nouvelle page, il faut alors renseigner les champs nécessaires. Commençons par renseigner le titre, ainsi que la description de l'issue :
Titre de l'issue :
[EPIC] Gestion des vétérinairesDescription de l'issue :
Dans le projet *PetClinic*, il faut ajouter la gestion des vétérinaires.
Implémentation de :
- Création des vétérinaires
- Recherche des vétérinaires
- Mise à jour des vétérinaires
- Suppression des vétérinaires
Tâches à faire :
- [x] Création des vétérinaires
- [x] Recherche des vétérinaires
- [x] Mise à jour des vétérinaires
- [ ] Suppression des vétérinaires
- [ ] Supprimer les vétérinaires
- [x] Suppression de la base de donnéesAjoutez-lui le label Epic :
Et enregistrez en cliquant sur le bouton Submit Issue.
Créez votre première user story
La deuxième issue sera de type user story. Ajoutez une nouvelle issue en cliquant sur le bouton New Issue :
Titre de l'issue
[User story] Suppression du vétérinaireDescription de l'issue
En tant qu'administrateur, je dois pouvoir supprimer un vétérinaire afin que celui-ci ne s'affiche plus dans l'applicationEt enregistrez-la.
Si vous revenez sur la liste des issues, vous avez maintenant deux issues créées :
Organisez votre backlog
Nous allons maintenant associer la user story fraîchement créée à l'epic que l'on a créée auparavant. Pour ce faire, il suffit d'aller sur la description de l'epic, de cliquer sur le bouton +, au niveau du menu Related Issues, d'ajouter le numéro de la user story (dans mon cas, #5), et de cliquer sur Add.
Si nous retournons maintenant sur le menu Boards, nous allons voir que sur les deux boards créés (Development et Product), dans la partie Open, nous avons nos deux issues créées précédemment :
Cependant, nous ne voulons voir ici que les issues associées à chacun des boards (user stories pour le board Development, et epic pour le board Product). Pour ce faire, il suffit de cliquer sur le bouton Edit Board, et d'ajouter uniquement les labels qui nous intéressent :
En modifiant les boards, nous nous retrouvons bien avec les issues qui nous intéressent sur chacun des boards.
En déplaçant nos issues sur chacun des boards, nous pouvons jouer sur la priorisation des epics, ou l'avancement des user stories.
La dernière chose à faire est de créer un sprint, et de voir le burndown chart associé. Pour ce faire, il faut aller dans le menu Milestones, et cliquer sur le bouton New Milestone.
Ensuite, il suffit de remplir les informations du sprint, et de cliquer sur le bouton Create Milestone :
Nous avons maintenant accès au burndown chart du sprint en cours :
Afin d'associer des issues au sprint en cours, il suffit d'aller sur chacune des issues que l'on souhaite associer au sprint, et de modifier leur propriété sur le menu à droite. Dans cet exemple, j'ai modifié le milestone, le time tracking (en commentant l'issue avec les commandes /estimate et /spend), la due date, le weight, et je me suis assigné l'issue :
Dorénavant, toute l'équipe pourra suivre l'avancement du burndown chart facilement :
En résumé
Dans ce chapitre, vous avez planifié le développement de votre application grâce à GitLab. Vous avez créé votre backlog et vos issues (epic et user stories), que vous avez organisées afin d'assigner les tâches.
Dans le prochain chapitre, nous passerons aux étapes 2 et 3.
