Dans ce chapitre, nous allons nous servir de GitLab comme d’un 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 instance GitLab en local.
Si vous n’avez pas encore de compte sur GitLab, je vous invite à vous en créer un, puis à vous connecter.
Activez la sécurité de votre projet
Il est également possible de raccorder votre annuaire d’entreprise à Gitlab afin de bénéficier d’une authentification unique à travers les accès de votre entreprise. C’est ce qu’on appelle le Single Sign-On (SSO) ou authentification unique en français. Le SSO vous permet aussi d’authentifier plus précisément chaque commit effectué sur le code source ; un commit étant un regroupement de changements fait dans le code. Dans ce cas, il sera plus difficile pour une personne malveillante de pouvoir commiter du code malveillant dans vos applications et celles-ci sont donc plus sécurisées.
Avec l’authentification par SSO, il est maintenant possible de configurer votre client Git afin d’authentifier fortement vos commits. Ainsi, à chaque commit est associée une personne qui permet de tracer en détail qui fait quoi et à quel moment dans le projet.
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 deuxième chapitre de ce cours, 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 votre projet, je vous invite à suivre les étapes présentées dans la vidéo ci-dessous.
Appréhendez le DevSecOps
Dans l’approche DevSecOps, nous essayons de remettre la sécurité au cœur du développement des applications et non à la fin. Pour intégrer directement la sécurité dans le backlog, trois nouvelles catégories, directement liées au Shift Left de la sécurité, sont créées :
L’Evil User Story est une spécialisation d’une User Story normale et représente ce qu’un acteur malveillant pourrait faire à votre application. Généralement, l’Evil User Story commence toujours par une phrase du type “Un attaquant ne devrait pas pouvoir…”.
L’Abuser Story, quant à elle, est aussi une spécialisation d’une User Story et représente le point de vue d’un acteur malveillant. Cette User Story est utilisée pour représenter les activités qui devraient être bloquées ou atténuées. Par exemple, une Abuser Story pourrait être : “En tant que client authentifié, je vois ce qui ressemble à mon numéro de compte dans l’URL, alors je le remplace par un autre numéro pour voir ce qui se passe.”.
La Vulnerability est une spécialisation du bug et représente une vulnérabilité connue de l’application ou de ces dépendances.
Commencez le workflow de développement
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. Une epic est une description de haut niveau de ce que le client veut et, par conséquent, elle a une certaine valeur.
Ces epics doivent faire apparaître plusieurs critères, comme des wireframes ou autres écrans définissant l’application. Une epic en priorité haute migre 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 trois issues :
une epic ;
une user story ;
une evil 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ées> Ajoutez-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.
Nous allons aussi créer une autre user story de type Evil User Story qui vous montrera un exemple de ce que peut être la prise en compte de la sécurité dans le cycle de développement logiciel.
Ajoutez une nouvelle issue en cliquant sur le bouton New Issue :
Titre de l’issue
[Evil User story] Vol de données personnellesDescription de l’issue
En tant que pirate, je veux m’introduire dans le compte d’un utilisateur spécifique, afin de pouvoir voler ses données personnellesEt enregistrez-la.
Si vous revenez sur la liste des issues, vous avez maintenant trois issues créées :
Organisez votre backlog
Pour organiser votre backlog, je vous invite à suivre les étapes présentées dans la vidéo ci-dessous.
Dans ce screencast, nous avons pu associer deux issues afin de créer une hiérarchie correspondant à la norme Scrum (Epic > User story). Nous avons vu aussi comment ajouter deux boards afin de pouvoir filtrer les issues créées par board : les Epics pour le Product backlog et les User story pour le Development backlog. Enfin, nous avons priorisé ces issues pour chaque sprint en utilisant les Milestones de Gitlab.
En résumé
Dans GitLab, pour assurer la sécurité de son code, on peut utiliser l’authentification à deux facteurs et le Single Sign-On.
L’approche DevSecOps met la sécurité au cœur du développement des applications.
Les issues permettent de tracer vos développements dans GitLab.
Le backlog s’organise en utilisant la méthode Scrum.
Maintenant que vous avez défini votre Sprint Backlog, vous allez pouvoir aborder le développement, la compilation et l’intégration du code, ainsi que l’étape de test dans le chapitre suivant.
