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.
[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).
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.
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 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 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.
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 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.
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.
Sous le signe de l'encadrement, cette première semaine est dite « douce » :
* 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 : Planification
Vient ensuite une phase d'organisation avec :
* 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 :
* une configuration de Gitlab, des principaux dépôts Gitlab, des branches, etc.,
* de s'organiser en équipe : définir des méthodologies à suivre.
#### Semaine 3 : 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 :
* 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 : Conception de l’infrastructure
Vient ensuite la création de la couche basse de l'infrastructure :
* 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 : Gestion des données
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.
