soutenance/content/20_cahier_des_charges.md

\newpage

# Cahier des charges

Premier élément du projet sur lequel travailler : le cahier des charges.

## Contexte

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} 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**.

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é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

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'éverture à proposer une situation proche de la réalité afin que l'équipe nouvellement formée puisse apprendre par la pratique.

On imagine ainsi le cadre suivant&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.

De la même manière, on imagine de l'entreprise une façon de fonctionner ayant de nombreux problèmes&nbsp;: 

* 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 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

En dehors des objectifs à atteindre, le projet vise à&nbsp;: 

* 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

D'après moi, ce projet à plusieurs objectifs&nbsp;: 

* 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

Voici le détail de chaque étape de travail.

#### Semaine 1&nbsp;: Cadrage

Sous le signe de l'encadrement, cette première semaine est dite « douce »&nbsp;: 

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

Vient ensuite une phase d'organisation avec&nbsp;: 

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

* 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.

#### Semaine 3&nbsp;: Automatisation de la chaine d’intégration et de livraison

Une fois les outils principaux mis en place, il s'agit d'automatiser certaines choses&nbsp;: 

* 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).

L'adoption d'un workflow pour la gestion des branches Git est la bienvenue.

#### Semaine 4&nbsp;: Conception de l’infrastructure

Vient ensuite la création de la couche basse de l'infrastructure&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.

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&nbsp;: Gestion des données

La semaine 5 passe par&nbsp;: 

* 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.