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

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.

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 fournis initialement par Datascientest :
• canal du projet - sep24_bootcamp_devops : favorise l'échange entre DevU42 et le 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, 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 (fourni par Gitlab) permettant de rassembler les connaissances de l'équipe en un seul endroit,
• Framapad, 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 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.

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