15 KiB
\newpage
Cahier des charges
Dans le cadre d'une formation, dans l'école DataScientest, il a été demandé à des équipes composées de 3 à 5 personnes de travailler sur un projet défini, cadré et suivant un certain nombre de contraintes dont nous allons parler ici.
Le cahier des charges a été la première réflexion sur le projet.
Contexte
Commençons par le contexte du projet avec l'ensemble des intervenants et des contraintes attenantes.
Dans le cadre d'une formation
[Datascientest]{#datascientest} est une école de formation créée en 2017, située sur Paris et proposant plus de 18 formations différentes, dont Administrateur Système DevOps.
Plusieurs formats de formation existent parmi Bootcamp, continu et en alternance. Ce projet est un exercice de fin de formation proposé à tous les élèves de la « cohorte » (équivalent d'une classe).
Plusieurs élèves se regroupent autour d'un projet auquel ils ont un intérêt commun.
L'équipe DevU42
Le groupe DevU42 s'est formé le 17 octobre 2024. Il est composé de quatre étudiants participant à la formation Administrateur Système DevOps de l’organisme de formation DataScientest.
Ses membres sont, par ordre alphabétique (prénom) :
- Eliel MONCADA
- Hrubech HOMBESSA
- Julien SABIOLS
- Olivier DOSSMANN
Ils interviennent sur le projet en qualité d’Administrateur Système DevOps.
L'équipe a été supervisée et suivie par [Jérémie Tarot sous la dénomination de « Mentor »]{#mentor}. Et ainsi en sera-t-il dans le présent document.
Organisation d'équipe
Pour s'organiser, l'équipe s'est doté de plusieurs outils et suivi quelques méthodologies.
Rapports hiérarchiques
L’équipe s'articule autour de membres ayant le même degré de responsabilités et d'objectifs. Leur périmètre et leur champ d'action est similaire qu'il s'agisse de déterminer les tickets à prendre en charge, les axes de travail à rajouter au projet ou bien de nouveaux objectifs.
En cas de désaccord sur un sujet, une décision est prise à la majorité votante, avec pour ultime recours l’avis du Mentor.
Moyens de communication
La géolocalisation des membres de l'équipe étant éparse, plusieurs moyens de communication en ligne ont été nécessaires, parmi :
- Canaux de discussions sur Slack fournis initialement par Datascientest :
- Un nom de domaine, devu42.fr,
- Une boîte courriel, team@devu42.fr partagée pour la gestion des services,
- Groupe DevU42 sur Gitlab, un outil intégré avec gestion d'équipe, gestion de projet, gestion de tickets, gestion de tableau de bord (kanban), gestion de dépôts, gestion de paquets, etc.
- Un wiki, DevU42 sur Gitlab (fourni par Gitlab) permettant de rassembler les connaissances de l'équipe en un seul endroit,
- Framapad, un éditeur de texte collaboratif pour les divers travaux de rédaction.
Contraintes initiales
Deux principales contraintes initiales avaient été imposées dans le cadre de la formation :
- le budget,
- le temps.
Budget
Le budget alloué au projet est de 150€ mensuel pour couvrir l'intégralité des frais issus de l'utilisation de services Amazon (AWS).
C'est une limite configurée par Datascientest sur l'espace Amazon qu'ils nous partagent.
Temps
Le temps alloué pour réaliser ce projet avant un premier lancement officiel est fixé à 7 semaines.
Au terme des 7 semaines, un support visuel de présentation du projet pour son lancement est attendu (Cf. Section du présent chapitre sur les Livrables).
Après livraison, l’amélioration du projet est possible, bien qu'un dossier professionnel, un dossier de projet (ci-présent) et un support de présentation est demandé à chacun des membres de l'équipe DevU42.
Le projet
Le point de départ du projet est un dépôt de version contenant une application à mettre en ligne. Justification du projet, l'application elle-même, ambitions et objectifs sont des points à soulever.
Justification du projet
L'école de formation DataScientest s'évertue à proposer une situation proche de la réalité afin que l'équipe nouvellement formée puisse apprendre par la pratique.
On imagine facilement le cadre :
Une entreprise ayant une application de gestion d’utilisateur souhaite déployer et faire évoluer son service en favorisant les bonnes pratiques suivies dans la culture DevOps.
De la même manière, l'entreprise pourrait rencontrer de nombreux problèmes :
- Reprise d’activité lente, coûteuse et avec pertes d’informations,
- Service instable, disponibilité non garantie, vulnérabilité du service,
- Capacité limitée pour encaisser des augmentations ponctuelles de la charge et du trafic,
- Absence de supervision et faible capacité à prévoir les problèmes,
- Manque de contrôle sur la qualité du code ; procédures de développement pouvant être améliorées par l'automatisation,
- Perte de temps et erreurs humaines liées aux actions manuelles,
- Manque de portabilité de l'application d'un système à l'autre,
- Lenteurs d’implémentation de nouvelles fonctionnalités avec interruptions de service.
Pour bien saisir l'état des lieux de ladite application, regardons de plus près.
Application existante
L'application FastAPI-Træfik est fournie avec les éléments principaux suivants :
- Backend utilisant le framework FastAPI (en Python),
- Frontend statique (en React, Vite.js et Chakra UI) : Interface de gestion et d'enregistrement d’utilisateurs utilisant l'API du backend,
- Base de données postgreSQL,
- et Traefik (Proxy inverse).
Tout ceci est déposé dans un dépôt de version avec de la documentation en fichier Markdown (*.md) bruts.
De simples fichiers Docker et docker-compose.yml permettent aux développeurs de lancer l'application localement.
Une procédure manuelle existe pour expliquer comment mettre l'application en production sur une machine serveur dédiée.
Mais le projet voit plus loin.
Ambitions
En dehors des objectifs à atteindre, le projet vise à :
- répondre aux problématiques de l’entreprise sur l'application existante par la méthode DevOps,
- répondre aux attentes de l’examen en matière de compétences attendues (méthode d'apprentissage par la pratique),
- démontrer un savoir-faire technique sur les sujets principaux du DevOps, notamment vis à vis du Cloud en utilisant AWS (Amazon Web Services),
- appliquer une méthode de travail qui optimise l’efficacité de la production des livrables.
C'est de ces ambitions que naîssent plusieurs objectifs spécifiques.
Objectifs
D'après moi, ce projet à plusieurs objectifs :
- balayer l'ensemble des sujets liés à la culture DevOps et ses méthodes,
- porter, puis déployer une application sur le cloud,
- préparer une architecture complète pour accueillir une à plusieurs applications,
- respecter un budget et des limites de temps,
- déployer en continu un projet en passant par une phase de test, de pré-production puis de production,
- penser à la gestion de la donnée,
- superviser un système déployé en production avec des tableaux de bord efficaces,
- rendre un système résilient en prenant en compte les augmentations ET les diminution de charges et par une haute disponibilité,
- automatiser la plupart des actions afin de limiter les erreurs humaines,
- procéder, de manière automatique, à des vérifications sur la sécurité des éléments produits et déployés,
- favoriser une collaboration plus fluide entre les équipes de développements et les équipes d'opérations,
- et obtenir des alertes en cas de défaillance d'un ou plusieurs éléments du système.
Ce sont des objectifs plutôt ambitieux pour un temps aussi court. Un travail d'équipe et une organisation de cette dernière sont totalement primordiaux.
Planification
C'est par le mentor que nous avons reçu le plan d'action pour les 7 semaines de travail à venir et une liste de livrables attendus. Nous avons adapté ce plan d'action pour nous correspondre.
Étapes de travail
Commençons par le détail de chaque étape. Pour les 7 semaines à venir.
Semaine 1 : Cadrage
Sous le signe de l'encadrement, cette première semaine est dite « douce » :
- réunion de prise de contact, présentation et cadrage,
- introduction de chaque membre du projet,
- découverte de l'application,
- analyse du sujet,
- évaluation du contexte, des objectifs et du périmètre du projet,
- et rédaction du premier jet du présent cahier des charges.
Il faut ce temps pour découvrir de quoi il retourne.
Semaine 2 : Planification
Vient ensuite une phase d'organisation avec :
- définition du contexte, des objectifs et du périmètre du projet,
- organisation des exigences,
- identification des composants d'architecture,
- choix de solutions à implémenter,
- et définition de l'architecture et les spécifications du système cible.
Ce qui amène à compléter le cahier des charges.
Nous prévoyons aussi :
- une configuration de Gitlab, des principaux dépôts, des branches, etc.,
- de s'organiser en équipe : définir des méthodologies à suivre.
Semaine 3 : Automatisation de la chaine d’intégration et de livraison
Une fois les outils principaux mis en place, il s'agit d'automatiser plusieurs parties :
- automatisation des tests pour le backend et le frontend,
- création d'image Docker pour le backend,
- création d'image Docker pour le frontend,
- automatisation des images Docker et de leur publication sur des registres d'images,
- création de chart Helm pour le backend,
- création de chart Helm pour le frontend,
- automatisation de la création des chart Helm et de leur publication sur des registres d'images,
- et automatisation de la création de l'infrastructure (même si elle n'est pas encore clairement définie).
L'adoption d'un workflow Git pour la gestion des branches est la bienvenue.
Semaine 4 : Conception de l’infrastructure
Vient ensuite la création de la couche basse de l'infrastructure :
- création d'un schéma de la couche basse de l'infrastructure,
- description de cette infrastructure via des modules adaptés et en adoptant l'Infrastructure as Code (IaC),
- premiers choix de solutions pour le stockage, les sauvegardes, la supervision et l'environnement d'accueil de l'application,
- activation des certificats Let's Encrypt,
- liaison avec le nom de domaine,
- et mise à l'échelle automatique.
Une semaine n'est pas suffisante pour traiter tous les sujets. En revanche cela permet de les aborder et d'échanger sur ces derniers.
Semaine 5 : Gestion des données
Possiblement en parallèle du sujet de la semaine 6 sur l'Observabilité et des alertes, la gestion des données est importante et passe par :
- créer et configurer des ressources de stockage de données,
- mise en place de politique d'authentification et d'autorisation,
- import des données,
- et installer/configurer une solution de sauvegarde et de restauration de données.
C'est un sujet bien à part. D'où la possibilité de la faire en parallèle d'un autre.
Semaine 6 : Observabilité et alertes
Quant à la semaine 6, nous avons principalement la supervision à gérer :
- configuration du système de supervision centralisé,
- mise en place d'une collecte de surveillance pertinente pour l'application,
- choix des métriques à utiliser pour la création de tableaux de bords,
- création des tableaux de bords,
- définition des niveaux d'alertes pour les métriques choisis,
- mise en place des alertes,
- et envoi des alertes sur les canaux choisis.
Ces éléments pourront être complétés et étendus une fois la solution principale de supervision configurée.
Semaine 7 : Présentation de la solution finale
Cette dernière semaine ciblera la présentation et le lancement officiel de l'application. Il faudra donc :
- compléter les documentations,
- mettre à jour les schémas en fonction d'éventuels changements,
- préparer un support visuel de présentation du projet,
- veiller à ce que l'application tourne sans accrocs pour la présentation,
- et résoudre les derniers problèmes majeurs connus - s'ils existent.
C'est un plan ambitieux quand on considère que les membres de l'équipe proviennent d'horizons et de formations variées.
Livrables
Sont attendus les livrables suivants :
- un cahier des charges,
- une présentation par diapositives pour le lancement de l'application,
- une application déployée en production, sans bugs,
- un système de supervision de la production,
- une gestion des données avec un système de sauvegarde,
- un schéma de la couche basse de l'infrastructure utilisée dans le Cloud pour la production,
- un accès aux dépôts et scripts permettant l'automatisation du déploiement de l'application et de la génération des différents éléments (images Docker, Chart Helm, registres, etc.),
- et un fonctionnement en haute disponibilité de l'application.
Conclusion
Le projet couvre beaucoup de situations et domaines autour de l'automatisation et la mise en production, dans le Cloud, d'une application avec une supervision et une mise à l'échelle de cette dernière.
En groupe, c'est un projet idéal pour suivre l'« apprentissage par la pratique » proposé par DataScientest et couvrir un maximum de compétences demandées pour le Titre Professionnel d'Administrateur Système DevOps.