chore(content): Write on 'Cahier des charges'
This commit is contained in:
parent
2fc828ce2b
commit
9ac066cf50
10
TODO
Normal file
10
TODO
Normal file
@ -0,0 +1,10 @@
|
||||
# TODO list
|
||||
|
||||
## Orga
|
||||
|
||||
* faire des "liens" {mot-clé} pour CHAQUE titre
|
||||
|
||||
## Remerciements
|
||||
|
||||
* Trouver adjectifs pour chacun
|
||||
* Faire un beau paragraphe pour la plupart
|
||||
@ -3,3 +3,17 @@
|
||||
# Liste de compétences couvertes par le projet
|
||||
|
||||
TODO: Lister compétences du référentiel
|
||||
|
||||
* Automatiser la création de serveurs à l'aide de scripts
|
||||
* Automatiser le déploiement d'une infrastructure
|
||||
* Mettre l'infrastructure en production dans le cloud
|
||||
* Préparer un environnement de test
|
||||
* Gérer des containers
|
||||
* Automatiser la mise en production d'une application avec une plateforme
|
||||
|
||||
Ne couvre pas - pour le moment :
|
||||
|
||||
* Sécuriser l'infrastructure
|
||||
* Gérer le stockage des données
|
||||
* Définir et mettre en place des statistiques de services
|
||||
* Exploiter une solution de supervision
|
||||
|
||||
@ -3,3 +3,216 @@
|
||||
# Cahier des charges
|
||||
|
||||
TODO: cahier des charges
|
||||
|
||||
## Contexte
|
||||
|
||||
TODO : présenter Datascientest succinctement (dans un sous titre ?)
|
||||
|
||||
### Dans le cadre d'une formation
|
||||
|
||||
[Datascientest]{#datascientest}
|
||||
|
||||
TODO: compléter ici ce que Datascientest fait
|
||||
|
||||
### 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**.
|
||||
|
||||
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
|
||||
|
||||
#### 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é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,
|
||||
* [**Gitlab**, DevU42](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](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**.
|
||||
|
||||
Après livraison, l’amélioration du projet en continu se fera sur **6 semaines supplémentaires** durant lesquelles un dossier professionnel et un support de présentation est demandé à chacun des [membres de l'équipe](#devu42).
|
||||
|
||||
## Le projet
|
||||
|
||||
### Justification du projet
|
||||
|
||||
Le projet s’inscrit dans le cadre suivant :
|
||||
|
||||
Une entreprise a besoin que son application de gestion d’utilisateur soit portée par les pratiques DevOps, pour faire évoluer son service.
|
||||
|
||||
De nombreux problèmes sont constatés avec la façon de fonctionner actuelle :
|
||||
|
||||
* 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
|
||||
|
||||
### 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)
|
||||
|
||||
### 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.
|
||||
|
||||
### 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.
|
||||
|
||||
## Planification
|
||||
|
||||
### Étapes de travail
|
||||
|
||||
Semaine 1 : Choix du projet
|
||||
|
||||
* 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 2 : Planification
|
||||
|
||||
* 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.
|
||||
|
||||
Semaine 3 : Automatisation de la chaine d’intégration et de livraison
|
||||
|
||||
* 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 4 : Conception de l’Infrastructure
|
||||
|
||||
* 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
|
||||
|
||||
Semaine 5 : Gestion des données
|
||||
|
||||
* 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
|
||||
|
||||
Semaine 6 : Observabilité et Alertes
|
||||
|
||||
* 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 7 : Préparer la communication
|
||||
|
||||
* 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
|
||||
|
||||
### Livrables attendus
|
||||
|
||||
Documents informatifs :
|
||||
|
||||
* Cahier des charges
|
||||
* Support de communication diapositive
|
||||
* Schéma pour chaque préoccupation majeure
|
||||
* Dossier de projet
|
||||
|
||||
Gitlab :
|
||||
|
||||
* 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
|
||||
|
||||
L’application :
|
||||
|
||||
* L’accès au backend
|
||||
* L’accès sécurisé https à notre Frontend
|
||||
* Le tout via notre propre nom de domaine
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user