\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 {#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](#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](#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](https://slack.com/intl/fr-fr/)** fournis initialement par [Datascientest](#datascientest) : * canal du projet - **sep24_bootcamp_devops** : favorise l'échange entre [DevU42](#devu42) et le [Mentor](#mentor), * canal d'équipe - **devu42** : pour les **discussions techniques**, les choix décisifs et de la bonne humeur ! * Un nom de domaine, **devu42.fr**, * Une boîte courriel, **** partagée pour la **gestion des services**, * [**Groupe DevU42 sur Gitlab**](https://gitlab.com/devu42/), 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](https://gitlab.com/devu42/projet/-/wikis/home) (fourni par Gitlab) permettant de rassembler les **connaissances de l'équipe** en un seul endroit, * [**Framapad**](https://framapad.org/abc/fr/), 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](#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](#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](#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](#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](#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](#semaine6), 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 {#semaine6} 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 {#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](#datascientest) et couvrir un maximum de compétences demandées pour le *Titre Professionnel d'Administrateur Système* DevOps.