soutenance/content/20_cahier_des_charges.md

\newpage

# 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&nbsp;: 

* 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&nbsp;: 

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&nbsp;: 

* 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&nbsp;: 

* Cahier des charges
* Support de communication diapositive
* Schéma pour chaque préoccupation majeure
* Dossier de projet

Gitlab&nbsp;: 

* 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&nbsp;: 

* L’accès au backend
* L’accès sécurisé https à notre Frontend
* Le tout via notre propre nom de domaine