Bienvenue les cadettes et les cadets ! Vous avez été choisis pour rejoindre le Front de Libération d'Internet. Nous avons une nouvelle commande ! Un citoyen zombie souhaite que nous réalisions un site de recettes pour sa communauté. Votre promo a été choisie pour me prêter main forte sur ce projet.
Dans un premier temps, nous allons faire un recueil des besoins pour cette commande et créer un tableau de bord afin de gérer l'organisation du développement. Pour ce faire, nous allons utiliser le service dédié sur Gitlab. Pour pouvoir m'accompagner, votre première mission sera donc de vous inscrire sur Gitlab et créer un premier projet.
Créer un projet sur Gitlab
Une fois sur Gitlab, allez en haut à gauche de votre écran, sur le bouton marqué d'un "+", et mettez "New project/repository" (tout au long de ces cours vous allez devoir vous habituer à l'anglais car c'est la langue officielle du code).
Vous accédez alors à une page sur laquelle Gitlab nous demande quel type d'élément l'on souhaite créer. On peut réaliser plusieurs actions :
- Créer un projet vierge (Blank project).
- Créer un template.
- Importer un projet d'un autre gestionnaire de dépôt, comme Github, Bitbucket ou une instance personnelle de Gitlab.
- Lancer la CI/CD (Continuous Integration - Continuous Deployement = Intégration continue - Déploiement continu) d'un dépôt.
Nous allons créer un projet vierge, pour cela, cliquez sur l'élément avec le titre "Create blank project".
Vous arrivez alors sur une page de paramétrage de notre nouveau projet. On y voit plusieurs éléments à remplir :
- Project name : Vous pouvez mettre ce que vous souhaitez en nom de projet. Je vais mettre "Projet Zombie".
- Pick a group or namespace : Je vous conseille de mettre vos projets dans votre espace de nom personnel, en choisissant votre nom d'utilisateur dans la partie groups de la liste déroulante. Cela vous permettra de ne pas vous soucier des slugs des autres pour le vôtre. Je sélectionne mon nom d'utilisateur.
- Project slug. Un slug est une manière d'écrire une phrase compatible avec des URL. Dans ces dernières, vous ne pouvez pas mettre d'espaces, de caractères spéciaux, tels que des caractères accentués ou des caractères de ponctuation. Gitlab vous propose de "slugifier" le nom de projet directement et vous laisse la possibilité de le modifier à votre gré. Je laisse la valeur proposée par Gitlab.
- Project deployment target (optional) : Ce champ permet d'indiquer la technique qu'on va utiliser pour la mise en production de notre projet. Cette partie n'est pas importante à votre niveau. Comme ce n'est pas requis, on va le laisser vierge.
- Private/Public : Ces puces permettent de sélectionner la visibilité de votre projet. Pour cette partie je vous laisse libre de choisir.
- Privé : votre projet ne sera visible que par vous et les personnes que vous ajouterez à votre projet.
- Public : il sera visible par tout le monde.
- Project Configuration :
- Initialize repository with a README : Si vous le cochez, lorsque vous créez votre projet, Gitlab ajoutera pour vous un fichier appelé README ("LISEZ-MOI" en français). C'est un fichier à la racine du projet qui permettra d'avoir une page d'accueil propre pour votre dépôt. Comme nous allons initialiser notre projet nous-mêmes, nous créerons ce fichier à la main dans le prochain chapitre, donc décochez-le ici.
- Enable Static Application Security Testing (SAST) : Gitlab vous propose de fournir à votre projet des outils pour permettre de vérifier que vous n'utilisez pas des librairies avec des vulnérabilités. Comme nous n'allons pas utiliser de librairie pour ce projet, décochez-le également.
Et c'est parti, créez votre projet en cliquant sur le bouton "Create project".
Les cas d'utilisation
Vous arrivez maintenant sur une page qui affichera plus tard votre code. Ce qui nous intéresse, pour l'heure, est la fonctionnalité "Issues", visible sur la partie gauche de votre écran, dans l'onglet "Plan".
Notre première issue
Cliquez ensuite sur le bouton "New issue". Dans notre cas, la traduction de "an issue" serait "un problème" ou "une question". Ce système a été créé au départ pour lister les bugs d'une application. Aujourd'hui, on s'en sert toujours pour ça, mais aussi pour permettre de créer une liste des cas d'utilisation d'une application. Dans la version française, les traducteurs ont appelé cette partie "Tickets".
Sur le net, vous pourrez trouver beaucoup de modèles pour les cas d'utilisation ou cas d'usage ou use case en anglais. Je vais vous en proposer un qui est simple et clair ; il est composé de trois parties :
- La "user story" [obligatoire]
- Les critères d'acceptation [obligatoire]
- Les contraintes techniques [facultatif]
La user story
Notre user story est ici la description de ce que souhaite faire l'utilisateur final de notre application, pour la fonctionnalité décrite dans la cas d'usage. Voici un exemple en rapport avec notre projet. Un zombie cuistot souhaite entrer une nouvelle recette sur notre site. La user story pourrait ressembler à ça :
On voit que la syntaxe est fixée. Elle se compose de trois parties :
- En tant que ...
- je [souhaite] + verbe d'action
- afin de ...
Le verbe "souhaiter" est facultatif, dans certain cas le verbe d'action se suffit à lui-même :
Les critères d'acceptation
Ils vont lister tous les scénarios possibles, afin d'être exhaustif dans la description de notre cas d'usage. Les développeurs vont s'en servir afin d'implémenter tous les comportements potentiels dans leur code.
Si l'on reprend notre exemple de cas d'usage, pour rentrer une nouvelle recette, voici les critères d'acceptation possibles :
Dans cet exemple, on peut voir trois scénarios en échec et un valide. Comme pour les user stories, les critères d'acceptation ont ici une forme très structurée. On utilise la syntaxe Gherkin :
- Scénario : <titre du scénario> => le titre permet de retrouver plus rapidement le scénario qui nous intéresse dans la liste.
- Étant donné que = état initial
- Lorsque = action de l'utilisateur
- Alors = action réalisée par l'application en réaction à l'action de l'utilisateur
- Des "Et" peuvent être ajoutés aux trois points ci-dessus, afin de lister plusieurs critères dans une même catégorie.
Les contraintes techniques
Cette partie est faite pour ajouter des informations utiles au développement, lorsqu'elles ne sont pas directement liées à une action de l'utilisateur. Par exemple, les informations pour pouvoir créer la table "Recipe" dans la base de données.
Les étiquettes
Créer une étiquette
Pour regrouper et organiser vos issues, vous pouvez ajouter des étiquettes (labels en anglais). Elles vous permettent de rassembler les cas d'usage par thème. Dans le menu à gauche, allez sur "Manage" > "Labels".
Utilisez plusieurs fois "New label" pour créer cet ensemble d'étiquettes :
- To do
- En cours
- Terminée
- Recette
- Sécurité
- Administration
Si vous aviez cliqué sur "Generate a default set of labels", Gitlab aurait créé cet ensemble par défaut :
- bug
- confirmed
- critical
- discussion
- documentation
- enhancement
- suggestion
- support
Ajouter des étiquettes à une issue
Quand vous êtes sur l'issue, dans le menu de droite, cliquez sur le bouton "Edit" de la catégorie "Labels".
Si l'on reprend notre exemple, vous pouvez lier les labels suivants :
- Recette
- Administration
Les types d'étiquette
Même s'il n'y a pas vraiment des types différents, on crée souvent des étiquettes pour deux raisons différentes : les types de fonctionnalités et organiser les issues dans le projet.
Les types de fonctionnalités
Les issues seront regroupées en fonction de ces étiquettes. Une même issue peut être dans plusieurs catégories. Comme vous pouvez voir si vous allez sur la liste des issues pour notre projet vous avez des issues qui sont dans "Administration" et dans "Recette", alors que certaines ne sont que dans "Recette".
Ces étiquettes servent à organiser les issues en ensemble logique et pour filtrer quand on a une longue liste d'issues.
Les étiquettes d'organisation
Ces étiquettes sont souvent : "To do", "En cours", "En test" et "Terminée". Elles sont liées à un autre outil dans gitlab : le tableau de bord des issues.
Quand vous arrivé la première fois sur cette page, vous n'avez que deux colonnes : "Open" et "Closed". Si vous n'avez fermé aucune issue, elles seront alors toutes dans "Open". Pour notre projet, on va en créer des nouvelles à partir des étiquettes que vous avez créées plus haut.
Pour ajouter une nouvelle colonne, vous allez dans "Create list" en haut à droite du tableau de bord.
Ensuite, il va vous mettre une nouvelle colonne, et vous demandera de choisir dans une liste d'option l'étiquette associée. Prenez d'abord "To do".
Et il vous mettra la nouvelle colonne "To do" entre "Open" et "Closed". Puis recommencez avec les étiquettes "En cours" et "Terminée". Pour ce qui est de l'ordre de ces colonnes, vous pouvez le modifier comme vous voulez en utilisant un système de glissé/déposé (drag & drop).
Changer l'état d'une issue
Une fois que vous avez toute vos colonnes, vous pouvez modifier l'étape dans laquelle se trouve les issues. Par exemple, vous allez commencer la partie "recette" de votre site, vous glissez alors toutes vos issues en rapport avec les recettes dans la colonne "To do". Une fois que vous commencez réellement une nouvelle fonctionnalité, vous la déposez dans la colonne "En cours". Enfin, si vous avez terminé une fonctionnalité vous la mettez dans "Terminée".
Généralement une issue est passé dans "Closed" lorsqu'elle est mise en production, c'est-à-dire disponible pour tout le monde en ligne.
Pour modifier l'état, il vous suffit de faire un glissé/déposé pour placer l'issue d'une colonne à une autre. Quand vous êtes sur la page de détail d'une issue, vous pouvez aussi changer cet état en affectant une étiquette d'organisation, comme on l'a vu un peu plus haut.
Exercices
Pour vous entraîner, je vais vous demander d'écrire trois cas d'usage :
- Afficher les huit dernières recettes publiées sur la page d'accueil.
- Se connecter.
- En tant que contributeur, supprimer une de ses recettes, et en tant qu'administrateur, supprimer une recette.
Une fois que vous aurez terminé de les rédiger, vous pourrez vous rendre sur la liste des issues du projet d'entraînement pour comparer avec les vôtres. Elles ne seront jamais identiques, mais vérifiez au moins que vous n'avez pas oublié de condition ou de scénario.