chore(content): Cahier des charges - finished!

content/20_cahier_des_charges.md

@@ -2,17 +2,21 @@
 
 # Cahier des charges
 
-TODO: cahier des charges
+Premier élément du projet sur lequel travailler : le cahier des charges.
 
 ## Contexte
 
-TODO : présenter Datascientest succinctement (dans un sous titre ?)
+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.
 
 ### Dans le cadre d'une formation
 
-[Datascientest]{#datascientest}
+[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.
 
-TODO: compléter ici ce que Datascientest fait
+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}
 
@@ -31,6 +35,8 @@ L'équipe a été supervisée et suivie par [Jérémie Tarot sous la dénominati
 
 ### 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.
@@ -42,7 +48,7 @@ En cas de désaccord sur un sujet, une décision est prise à la majorité votan
 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 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éccisifs et de la bonne humeur !
 * Un nom de domaine, **devu42.fr**,
 * Une boîte courriel, <team@devu42.fr> partagée pour la gestion des services,
@@ -71,148 +77,194 @@ Après livraison, l’amélioration du projet en continu se fera sur **6 semaine
 
 ## 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
 
-Le projet s’inscrit dans le cadre suivant&nbsp;: 
+L'école de formation [DataScientest](#datascientest) s'éverture à proposer une situation proche de la réalité afin que l'équipe nouvellement formée puisse apprendre par la pratique.
 
-Une entreprise a besoin que son application de gestion d’utilisateur soit portée par les pratiques DevOps, pour faire évoluer son service.
+On imagine ainsi le cadre suivant&nbsp;: 
 
-De nombreux problèmes sont constatés avec la façon de fonctionner actuelle&nbsp;: 
+> 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.
 
-* Reprise d’activité lente, coûteuse et avec des pertes d’informations importantes
+De la même manière, on imagine de l'entreprise une façon de fonctionner ayant de nombreux problèmes&nbsp;: 
-* Stabilité et disponibilité du service vulnérable
+
-* Capacité limitée à encaisser les charges soudaines de trafic
+* Reprise d’activité lente, coûteuse et avec pertes d’informations,
-* Absence de supervision efficace, et de capacité à prévoir les problèmes
+* Service instable, disponibilité non garantie, vulnérabilité du service,
-* Manque de contrôle sur la qualité du code, et les procédures de développement
+* Capacité limitée pour encaisser des augmentations ponctuelles de la charge et du trafic,
-* Grande perte de temps lié aux nombreuses actions manuelles et aux erreurs humaines
+* Absence de supervision et faible capacité à prévoir les problèmes,
-* Possibilité d’évolution limité par le manque de portabilité
+* Manque de contrôle sur la qualité du code ; procédures de développement pouvant être améliorées par l'automatisation,
-* Lenteur de l’implémentation de nouvelles fonctionnalité, et interruptions de service
+* 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é 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 FastAPI (en Python)
+* BackEnd FastAPI (en Python),
-* FrontEnd (Interface de gestion et d’enregistrement d’utilisateurs. Statique, Utilise React, Vite.js, Chakra UI.)
+* FrontEnd (Interface de gestion et d’enregistrement d’utilisateurs. Statique, Utilise React, Vite.js, Chakra UI.),
-* Base de données
+* Base de données postgreSQL,
-* Traefik (Proxy inverse)
+* 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 existe pour expliquer comment manuellement mettre l'application en production sur une machine serveur dédiée.
+
+Mais le projet voit plus loin.
 
 ### Ambitions
 
-* Répondre aux problématiques de l’application existante par la méthode DevOps.
+En dehors des objectifs à atteindre, le projet vise à&nbsp;: 
-* Répondre aux attentes de l’examen en matière de compétences attendues.
+
-* Démontrer un savoir-faire technique sur les sujets principaux du Cloud dont AWS.
+* répondre aux problématiques de l’entreprise sur l'application existante par la méthode DevOps,
-* Appliquer une méthode de travail qui optimise l’efficacité de la production des livrables.
+* 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,
+* 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
 
-* Porter l’application sur le cloud, avec une architecture réseau dans le respect du budget.
+D'après moi, ce projet à plusieurs objectifs&nbsp;: 
-* Assurer une reprise d’activité en un minimum de temps.
+
-* Déployer automatiquement et en continu avec des fichiers modularisés.
+* balayer l'ensemble des sujets liés à la culture DevOps et ses méthodes,
-* Sauvegarder les données pour garantir leur conservation en cas de sinistre.
+* porter, puis déployer une application sur le cloud,
-* Etablir une sécurité multi-niveau qui garantisse l’intégrité de l’application et de l’architecture, sans
+* préparer une architecture complète pour accueillir une à plusieurs applications,
-  handicaper les travailleurs dans leur travail au quotidien.
+* respecter un budget et des limites de temps,
-* Rendre le système résilient, en assurant son auto-scalabilité et sa haute disponibilité.
+* déployer en continu un projet en passant par une phase de test, de pré-production puis de production,
-* Automatiser l’essentiel des actions pour limiter les erreurs humaines et gagner du temps.
+* penser à la gestion de la donnée,
-* Rendre le contrôle du code et des versions, systématique.
+* superviser un système déployé en production avec des tableaux de bord efficaces,
-* Mettre en place des solutions de supervisions et 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é,
-* Mettre en place un système d’alertes pour détecter les problèmes au plus tôt.
+* 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 sont totalement nécessaires.
 
 ## Planification
 
+C'est par le [mentor](#mentor) que nous avons reçu un plan d'action pour les 7 semaines de travail et une liste de livrables attendus. Nous avons adapté ce plan d'action pour nous correspondre.
+
 ### Étapes de travail
 
-Semaine 1 : Choix du projet
+Voici le détail de chaque étape de travail.
 
-* Constitution des groupes par l’organisme de formation
+#### Semaine 1&nbsp;: Cadrage
-* Choix du projet par le groupe nouvellement formé
-* Découverte de l’application en détail
-* organisation de l’équipe
-* choix des outils principaux et prise en main de ces derniers
 
-Semaine 2 : Planification
+Sous le signe de l'encadrement, cette première semaine est dite « douce »&nbsp;: 
 
-* Etablissement du présent cahier des charges 
+* réunion de prise de contact, présentation et cadrage,
-* Prise en main de l’application
+* introduction de chaque membre du projet,
-* Conception des schémas
+* découverte de l'application,
-* Choix des différents outils qui seront explorés les semaines suivantes
+* analyse du sujet,
-* Mise en place de l’organisation sur GitLab, et des procédures de travail
+* évaluation du contexte, des objectifs et du périmètre du projet,
-* Attribution de tâches par individu
+* et rédaction du premier jet du présent cahier des charges.
-* Exploration de projets similaires
-* Décider d’une première approche pour l’automatisation gitlab-ci
-* Décider des futurs repo/registry pour les images et les charts.
 
-Semaine 3 : Automatisation de la chaine d’intégration et de livraison
+Il faut ce temps pour découvrir de quoi il retourne.
 
-* Adoption de la méthode GitOneFlow
+#### Semaine 2&nbsp;: Planification
-* Mise en œuvre des deux environnements séparés Stagging et Prod
-* Développement des processus d’automatisation des :
-  - Tests
-  - Constructions/Compilations
-  - Livraison
-  - Déploiement
-* Mise en place de la promotion de version (basé sur Sem Ver)
-* Produire un schéma clair résumant nos dépôts et nos pipelines sur Gitlab.
 
-Semaine 4 : Conception de l’Infrastructure
+Vient ensuite une phase d'organisation avec&nbsp;: 
 
-* Définir la couche réseau de l’infrastructure sur AWS en haute disponibilité
+* définition du contexte, des objectifs et du périmètre du projet,
-* Assurer la sécurité des éléments de la couche réseau
+* organisation des exigences,
-* Prévoir une future solution de stockage
+* identification des composants d'architecture,
-* Adopter une solution de backup
+* choix de solutions à implémenter,
-* Définir la distribution de Kubernetes à employer, et la déployer.
+* et définition de l'architecture et les spécifications du système cible.
-* Gestion des secrets
-* Générer la redirection vers notre propre nom de domaine
-* Objectif : Infrastructure As Code
 
-Semaine 5 : Gestion des données
+Ce qui amène à compléter le cahier des charges.
 
-* Appliquer la méthode de stockage de données choisie
+Nous prévoyons aussi&nbsp;: 
-* Définir les politiques d’authentification, d’autorisation et de contrôle d’accès
-* Assurer une journalisation
-* Garantir la sauvegarde des données, et leur restauration en cas de sinistre
-* Mettre en place la scalabilité de la solution choisie.
-* Tester l’accessibilité des données par l’application
 
-Semaine 6 : Observabilité et Alertes
+* une configuration de Gitlab, des principaux dépôts Gitlab, des branches, etc.,
+* de s'organiser en équipe&nbsp;: définir des méthodologies à suivre.
 
-* Choisir une solution de monitoring 
+#### Semaine 3&nbsp;: Automatisation de la chaine d’intégration et de livraison
-* Définir les données d’analyse du système dans sa globalité, et multi-environnement
-* Créer des tableaux de bord pratiques et simples d’interprétation
-* Attribuer des alertes à certaines métriques
-* Tester des situations anormales pour constater si les alarmes se déclenchent correctement
 
-Semaine 7 : Préparer la communication
+Une fois les outils principaux mis en place, il s'agit d'automatiser certaines choses&nbsp;: 
 
-* Mettre à jour les schémas as code (Mermaid et Draw.io)
+* automatisation des tests pour le backend et le frontend,
-* Création du support de diapositives as code
+* création d'image Docker pour le backend,
-* Rédaction de la présentation, et entrainement individuel
+* création d'image Docker pour le frontend,
-* Tests de fonctionnement de l’implémentation d’une nouvelle fonctionnalité
+* automatisation des images Docker et de leur publication sur des registres,
-* Mise en commun des compétences et des connaissances en vue de la présentation
+* création de chart Helm pour le backend,
-* Fabrication d’un logo d’équipe
+* création de chart Helm pour le frontend,
-* Résolution des dernières améliorations
+* automatisation de la création des chart Helm et de leur publication,
+* et automatisation de la création de l'infrastructure (même si elle n'est pas encore clairement définie).
 
-### Livrables attendus
+L'adoption d'un workflow pour la gestion des branches Git est la bienvenue.
 
-Documents informatifs&nbsp;: 
+#### Semaine 4&nbsp;: Conception de l’infrastructure
 
-* Cahier des charges
+Vient ensuite la création de la couche basse de l'infrastructure&nbsp;: 
-* Support de communication diapositive
-* Schéma pour chaque préoccupation majeure
-* Dossier de projet
 
-Gitlab&nbsp;: 
+* 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.
 
-* Registre d’images docker
+Une semaine n'est pas suffisante pour traiter tous les sujets. En revanche cela permet de les aborder et d'échanger sur ces derniers.
-* Dépôt pour les charts
-* Dépôt de l’application initiale
-* Ensemble des fichiers de déploiement de l’architecture et des environnement modularisés
-* Pipelines (Gitlab-ci)
-* Le dépôt du projet
 
-L’application&nbsp;: 
+#### Semaine 5&nbsp;: Gestion des données
 
-* L’accès au backend
+La semaine 5 passe par&nbsp;: 
-* L’accès sécurisé https à notre Frontend
-* Le tout via notre propre nom de domaine
 
+* 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 et configurer une solution de sauvegarde et de restauration de données.
+
+Rien de très particulier à ce niveau là.
+
+#### Semaine 6&nbsp;: Observabilité et alertes
+
+Quant à la semaine 6, nous avons principalement la supervision à gérer&nbsp;: 
+
+* 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&nbsp;: Présentation de la solution finale
+
+Cette dernière semaine ciblera la présentation et le lancement officiel de l'application. Il faudra donc&nbsp;: 
+
+* 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 assez ambitieux quand on considère que les membres de l'équipe proviennent d'horizons et de formations variées.
+
+### Livrables
+
+Sont attendus les éléments suivants&nbsp;: 
+
+* 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ée par [DataScientest](#datascientest) et couvrir un maximum de compétences demandées pour le Titre Professionnel d'Administrateur Système DevOps.