chore(content): Cahier des charges - finished!
This commit is contained in:
parent
a62c095843
commit
fe3ac235d8
@ -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.
|
||||
@ -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 :
|
||||
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 :
|
||||
|
||||
De nombreux problèmes sont constatés avec la façon de fonctionner actuelle :
|
||||
> 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
|
||||
* Stabilité et disponibilité du service vulnérable
|
||||
* Capacité limitée à encaisser les charges soudaines de trafic
|
||||
* Absence de supervision efficace, et de capacité à prévoir les problèmes
|
||||
* Manque de contrôle sur la qualité du code, et les procédures de développement
|
||||
* Grande perte de temps lié aux nombreuses actions manuelles et aux erreurs humaines
|
||||
* Possibilité d’évolution limité par le manque de portabilité
|
||||
* Lenteur de l’implémentation de nouvelles fonctionnalité, et interruptions de service
|
||||
De la même manière, on imagine de l'entreprise une façon de fonctionner ayant 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é 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)
|
||||
* FrontEnd (Interface de gestion et d’enregistrement d’utilisateurs. Statique, Utilise React, Vite.js, Chakra UI.)
|
||||
* Base de données
|
||||
* Traefik (Proxy inverse)
|
||||
* BackEnd FastAPI (en Python),
|
||||
* FrontEnd (Interface de gestion et d’enregistrement d’utilisateurs. Statique, Utilise React, Vite.js, Chakra UI.),
|
||||
* 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 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.
|
||||
* 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.
|
||||
* Appliquer une méthode de travail qui optimise l’efficacité de la production des livrables.
|
||||
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,
|
||||
* 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.
|
||||
* Assurer une reprise d’activité en un minimum de temps.
|
||||
* Déployer automatiquement et en continu avec des fichiers modularisés.
|
||||
* Sauvegarder les données pour garantir leur conservation en cas de sinistre.
|
||||
* Etablir une sécurité multi-niveau qui garantisse l’intégrité de l’application et de l’architecture, sans
|
||||
handicaper les travailleurs dans leur travail au quotidien.
|
||||
* Rendre le système résilient, en assurant son auto-scalabilité et sa haute disponibilité.
|
||||
* Automatiser l’essentiel des actions pour limiter les erreurs humaines et gagner du temps.
|
||||
* Rendre le contrôle du code et des versions, systématique.
|
||||
* Mettre en place des solutions de supervisions et des tableaux de bord efficaces.
|
||||
* Mettre en place un système d’alertes pour détecter les problèmes au plus tôt.
|
||||
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 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
|
||||
* 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 1 : Cadrage
|
||||
|
||||
Semaine 2 : Planification
|
||||
Sous le signe de l'encadrement, cette première semaine est dite « douce » :
|
||||
|
||||
* Etablissement du présent cahier des charges
|
||||
* Prise en main de l’application
|
||||
* Conception des schémas
|
||||
* Choix des différents outils qui seront explorés les semaines suivantes
|
||||
* Mise en place de l’organisation sur GitLab, et des procédures de travail
|
||||
* Attribution de tâches par individu
|
||||
* 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.
|
||||
* 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.
|
||||
|
||||
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
|
||||
* 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 2 : Planification
|
||||
|
||||
Semaine 4 : Conception de l’Infrastructure
|
||||
Vient ensuite une phase d'organisation avec :
|
||||
|
||||
* Définir la couche réseau de l’infrastructure sur AWS en haute disponibilité
|
||||
* Assurer la sécurité des éléments de la couche réseau
|
||||
* Prévoir une future solution de stockage
|
||||
* Adopter une solution de backup
|
||||
* Définir la distribution de Kubernetes à employer, et la déployer.
|
||||
* Gestion des secrets
|
||||
* Générer la redirection vers notre propre nom de domaine
|
||||
* Objectif : Infrastructure As Code
|
||||
* 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.
|
||||
|
||||
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
|
||||
* 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
|
||||
Nous prévoyons aussi :
|
||||
|
||||
Semaine 6 : Observabilité et Alertes
|
||||
* une configuration de Gitlab, des principaux dépôts Gitlab, des branches, etc.,
|
||||
* de s'organiser en équipe : définir des méthodologies à suivre.
|
||||
|
||||
* Choisir une solution de monitoring
|
||||
* 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 3 : Automatisation de la chaine d’intégration et de livraison
|
||||
|
||||
Semaine 7 : Préparer la communication
|
||||
Une fois les outils principaux mis en place, il s'agit d'automatiser certaines choses :
|
||||
|
||||
* Mettre à jour les schémas as code (Mermaid et Draw.io)
|
||||
* Création du support de diapositives as code
|
||||
* Rédaction de la présentation, et entrainement individuel
|
||||
* Tests de fonctionnement de l’implémentation d’une nouvelle fonctionnalité
|
||||
* Mise en commun des compétences et des connaissances en vue de la présentation
|
||||
* Fabrication d’un logo d’équipe
|
||||
* Résolution des dernières améliorations
|
||||
* 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,
|
||||
* 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,
|
||||
* 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 :
|
||||
#### Semaine 4 : Conception de l’infrastructure
|
||||
|
||||
* Cahier des charges
|
||||
* Support de communication diapositive
|
||||
* Schéma pour chaque préoccupation majeure
|
||||
* Dossier de projet
|
||||
Vient ensuite la création de la couche basse de l'infrastructure :
|
||||
|
||||
Gitlab :
|
||||
* 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
|
||||
* 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
|
||||
Une semaine n'est pas suffisante pour traiter tous les sujets. En revanche cela permet de les aborder et d'échanger sur ces derniers.
|
||||
|
||||
L’application :
|
||||
#### Semaine 5 : Gestion des données
|
||||
|
||||
* L’accès au backend
|
||||
* L’accès sécurisé https à notre Frontend
|
||||
* Le tout via notre propre nom de domaine
|
||||
La semaine 5 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 et configurer une solution de sauvegarde et de restauration de données.
|
||||
|
||||
Rien de très particulier à ce niveau là.
|
||||
|
||||
#### 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 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 :
|
||||
|
||||
* 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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user