devu/soutenance
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(content): Limit to 80 chars per line. Complete with bold words.

Browse Source
This commit is contained in:
Olivier DOSSMANN 2025-02-19 17:53:38 +01:00
parent 2910e58a4c
commit 2c4be8ae9b
13 changed files with 1093 additions and 516 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Makefile
View File

@ -44,8 +44,8 @@ public/${NAME}.html: public ${CONTENT_LIST}
public/${NAME}.pdf: public ${CONTENT_LIST}
$Qecho "[PREPA] PDF : contenu"
# Cf. https://pandoc.org/chunkedhtml-demo/8.17-images.html for implicit_figures explanations (deactivated here)
$Qpandoc -V colorlinks -V fontfamily="${FONT_FAMILY}" -V fontsize="${FONT_SIZE}" -V classoption:twoside --number-sections -V graphics --template="${LATEX_TEMPLATE}" --toc -V toc-title:'${TOC_TITLE}' -V papersize:a4 --from=markdown-implicit_figures+fenced_code_attributes --highlight-style ${HL_THEME} --to=latex -o "public/${NAME}.pdf" ${CONTENT_LIST}
# Cf. https://pandoc.org/chunkedhtml-demo/8.17-images.html for implicit_figures explanations. Si activé : titre + centrées MAIS les images sont pas au bon endroit dans le texte. Si désactivé : pas de titre, pas centrées, MAIS images au BON ENDROIT.
$Qpandoc -V colorlinks -V fontfamily="${FONT_FAMILY}" -V fontsize="${FONT_SIZE}" -V classoption:twoside --number-sections -V graphics --template="${LATEX_TEMPLATE}" --toc -V toc-title:'${TOC_TITLE}' -V papersize:a4 --from=markdown+implicit_figures+fenced_code_attributes --highlight-style ${HL_THEME} --to=latex -o "public/${NAME}.pdf" ${CONTENT_LIST}
# END
.PHONY: clean

30
content/05_intro.md
View File

@ -2,32 +2,32 @@
# Introduction {#introduction}
La méthodologie Agile étant de plus en plus adoptée, les équipes de
développement publient de nouvelles versions de leur application avec une
fréquence bien plus élevée. Les équipes d'opération ont désormais besoin d'un
La **méthodologie Agile** étant de plus en plus adoptée, les **équipes de
développement** publient de nouvelles versions de leur application avec une
fréquence bien plus élevée. Les **équipes d'opération** ont désormais besoin d'un
outillage plus conséquent pour déployer ces versions. C'est pour cette raison
que l'automatisation, entre autre, est nécessaire pour soulager les équipes
d'opération. Ainsi le DevOps entre en jeu : une culture et un
ensemble de bonnes pratiques pour faciliter l'échange entre les équipes
de développement et celles d'opérations. Mais également de favoriser un flux
continu entre ces équipes.
que l'**automatisation**, entre autre, est nécessaire pour soulager les équipes
d'opération. Ainsi **le DevOps entre en jeu** : une culture et un
ensemble de **bonnes pratiques** pour faciliter l'échange entre les équipes
de développement et celles d'opérations. Mais également de favoriser un **flux
continu** entre ces équipes.
Au long de mon parcours, que ce soit en tant qu'Ingénieur en Conception et
Développement d’Environnements Distribués ou Responsable d'Applications, j'ai
Au long de mon parcours, que ce soit en tant qu'**Ingénieur en Conception et
Développement d’Environnements Distribués** ou **Responsable d'Applications**, j'ai
été sensibilisé aux besoin incessants de l'automatisation et de l'amélioration
des processus de création logiciel. J'ai participé à la mise en place
progressive d'une chaîne de publication logicielle, que ce soit dans le monde
professionnel ou dans la sphère privée pour publier mon blog. C'est donc tout
progressive d'une **chaîne de publication logicielle**, que ce soit dans le monde
professionnel ou dans la sphère privée (pour publier mon blog). C'est donc tout
naturellement que je me suis tourné vers ce domaine passionnant qu'est le
DevOps. Et ce à travers la formation DevOps en BootCamp au sein de l'organisme
DevOps. Et ce à travers la **formation DevOps en BootCamp** au sein de l'organisme
de formation DataScientest.
Le présent document présentera principalement le projet étudié lors de cette
formation. Nous commencerons par faire la corrélation entre les compétences
attendues pour le Titre Professionnel Administrateur Système DevOps et le(s)
attendues pour le *Titre Professionnel Administrateur Système DevOps* et le(s)
projet(s) présenté(s) dans ce dossier. Après quoi nous continuerons avec le
cahier des charges et les spécifications techniques de ce(s) dernier(s). \
Nous continuerons par expliquer la démarche suivi pour accomplir le projet,
Nous continuerons par expliquer la démarche suivie pour accomplir le projet,
quelques réalisations effectuées et d'une situation de travail qui mérite
d'être relevée.

99
content/08_remerciements.md
View File

@ -2,49 +2,104 @@
# Remerciements
Avant toute chose il y a une personne sans qui cette aventure n'aurait pas été possible : Agnès \textsc{Schweitzer}. Elle a été l'**immense soutien** derrière les petites mains qui écrivent ces lignes. Présente quand les choses n'allaient pas, quand la voie semblait sans issue et que l'iceberg s'approchait du bateau ! En sa précense l'humilité n'a qu'à bien se tenir !
Avant toute chose il y a une personne sans qui cette aventure n'aurait pas été
possible : **Agnès \textsc{Schweitzer}**. Elle a été l'**immense
soutien** derrière les petites mains qui écrivent ces lignes. Présente quand
les choses n'allaient pas, quand la voie semblait sans issue et que l'iceberg
s'approchait du bateau ! En sa précense l'**humilité** n'a qu'à bien se
tenir !
À Madame \textsc{Schweitzer} pour ses **conseils**, son aide **précieuse**, sa **présence d'esprit** et son **exceptionnelle intelligence** : MERCI !
À **Madame \textsc{Schweitzer}** pour ses **conseils**, son aide
**précieuse**, sa **présence d'esprit** et son **exceptionnelle
intelligence** : MERCI !
## À l'organisme de formation DataScientest
Nous avons parfois besoin d'un coup de pouce pour rejoindre les rails d'une autre ligne. C'est ce que permet l'organisme de formation **DataScientest** au travers de ses nombreux parcours proposés aux personnes qui, comme moi, souhaitent changer de métier.
Nous avons parfois besoin d'un coup de pouce pour rejoindre les rails d'une
autre ligne. C'est ce que permet l'organisme de formation **DataScientest**
au travers de ses nombreux parcours proposés aux personnes qui, comme moi,
souhaitent **changer de métier**.
Je remercie Sarah \textsc{Bouras} d'avoir été mon premier contact avec cet organisme. Elle a été **à l'écoute**, soucieuse de répondre **avec précision et parcimonie** à toutes mes questions et de me rassurer sur les sujets qui m'inquiétaient.
Je remercie Sarah \textsc{Bouras} d'avoir été mon premier contact avec cet
organisme. Elle a été **à l'écoute**, soucieuse de répondre **avec précision
et parcimonie** à toutes mes questions et de me rassurer sur les sujets qui
m'inquiétaient.
C'est ensuite Benjamin \textsc{Fiche}, chef de cohorte, qui a pris le pas en répondant consciencieusement à toutes mes questions ; même les plus triviales/simplettes/absurdes. Il a toujours fait preuve d'**un professionnalisme hors pair** et je me devais de le souligner.
C'est ensuite Benjamin \textsc{Fiche}, **chef de cohorte**, qui a pris le pas
en répondant **consciencieusement** à toutes mes questions ; même les plus
triviales/simplettes/absurdes. Il a toujours fait preuve d'**un
professionnalisme hors pair** et je me devais de le souligner.
Nous avons également Jérémie \textsc{Tarot}, notre passionnant - et passionné - Mentor qui détient une connaissance infinie des outils et des pratiques du monde du DevOps. Son savoir nous a donné de multiples pistes quand nous étions bloqués. Ses conseils ont été spécifiquement utiles lorsque les ressources venaient à manquer dans le projet, que ce soit en terme de ressources humaines ou de ressources temporelles. Il a cru en nous ; et ceci représente une aide précieuse.
Nous avons également Jérémie \textsc{Tarot}, notre **passionnant - et
passionné** - Mentor qui détient une **connaissance infinie** des outils
et des pratiques du monde du DevOps. Son savoir nous a donné de **multiples
pistes** quand nous étions bloqués. Ses conseils ont été spécifiquement utiles
lorsque les ressources venaient à manquer dans le projet, que ce soit en terme
de ressources humaines ou de ressources temporelles. Il a **cru en nous** ; et
ceci représente une aide précieuse.
Je remercie également l'ensemble de l'équipe DataScientest pour leur patience et leur savoir-vivre au regard de mes nombreux retours sur les cours, les examens et les machines virtuelles fournies.
Je remercie également **l'ensemble de l'équipe DataScientest** pour leur
patience et leur savoir-vivre au regard de mes nombreux retours sur les cours,
les examens et les machines virtuelles fournies.
## À l'équipe DevU42
Chaque membre de l'équipe a ses difficultés, une vie sociale et familiale prenante, des obligations et des responsabilités à côté de la formation.
Chaque membre de l'équipe a ses **difficultés**, une **vie sociale et
familiale** prenante, des **obligations** et des **responsabilités** à côté de
la formation.
Pris à part, nous avons chacun nos particularités. Ensemble ces problèmes étaient amoindris. Nous aurions pu faire mieux et plus loin. Mais nous avons faits. Et rien que pour cela je remercie l'équipe d'y être parvenu.
Pris à part, nous avons **chacun nos particularités**. Ensemble ces problèmes
étaient amoindris. Nous aurions pu faire mieux et plus loin. Mais nous avons
faits. Et rien que pour cela je remercie l'équipe d'y être parvenu.
À Eliel \textsc{Moncada} pour ses trouvailles Web et sa patience sur les schémas visuels qui prennent un temps considérable !
À Eliel \textsc{Moncada} pour ses **trouvailles** Web et sa **patience** sur
les schémas visuels qui prennent un temps considérable !
À Hrubech \textsc{Hombessa} pour sa qualité d'échange sur des sujets pointus et la pertinence de ses questions.
À Hrubech \textsc{Hombessa} pour sa **qualité d'échange** sur des **sujets
pointus** et la **pertinence** de ses questions.
À Julien \textsc{Sabiols} pour sa détermination, son travail acharné, son intelligence et son énorme humilité. Il a su être un partenaire de pair-programming brillant avec un esprit affûté. C'est rare. Et très appréciable !
À Julien \textsc{Sabiols} pour sa **détermination**, son **travail acharné**,
son **intelligence** et son énorme **humilité**. Il a su être un partenaire
de pair-programming **brillant** avec un **esprit affûté**. C'est rare. Et
très appréciable !
J'imagine que derrière chaque personne il y a également un ou une partenaire de vie qui a facilité l'organisation et la disponibilité autour de la formation. Pour ces personnes cachées dans l'ombre : MERCI ! Vous méritez de figurer dans ces lignes.
J'imagine que derrière chaque personne il y a également **un ou une partenaire
de vie** qui a facilité l'organisation et la disponibilité autour de la
formation. Pour ces personnes **cachées dans l'ombre** : MERCI !
Vous méritez de figurer dans ces lignes.
## Au membres de la « cohorte »
## Aux membres de la « cohorte »
Je tiens à remercier également l'ensemble des membres de la cohorte. À ceux qui ont participé aux discussions, à ceux qui ont bien voulu échanger, à ceux qui ont accepté de répondre à des questions, à ceux qui ont partagé des difficultés ou encore des solutions, à ceux qui étaient eux-même.
Je tiens à remercier également **l'ensemble des membres de la cohorte**. À
ceux qui ont participé aux discussions, à ceux qui ont bien voulu échanger,
à ceux qui ont accepté de répondre à des questions, à ceux qui ont partagé
des difficultés ou encore des solutions, à ceux qui étaient eux-même.
Une mention particulière aux personnes suivantes (ordre alphabétique - prénom) :
Une mention particulière aux personnes suivantes (ordre alphabétique -
prénom) :
* à Dorian \textsc{Roly} pour nos échanges intéressants sur de multiples technologies et sur les archétypes des personnes dans l'informatique,
* à Maxime \textsc{Boulanghien} pour sa sérénité, son implication et son efficacité sur des sujets dûments travaillés ; notamment la promotion logicielle au sein d'une automatisation complète de déploiement d'une infrastructure,
* à Michael \textsc{Lachand} pour nos discussions sur l'importance de l'individu au sein du domaine professionnel plutôt que des chiffres et des compétences seules ; mais aussi des difficultés apportés par notre Société moderne à ce sujet,
* et enfin à Philippe \textsc{Risser-Maroix} avec qui j'ai pu discuter de notions informatiques poussées et de Logiciel Libre sans me sentir seul à ce sujet ; sa sensibilité au sujet de la sécurité informatique est un point fort !
* à Dorian \textsc{Roly} pour nos **échanges intéressants** sur de multiples
technologies et sur les archétypes des personnes dans l'informatique,
* à Maxime \textsc{Boulanghien} pour sa **sérénité**, son **implication** et
son efficacité sur des sujets dûments travaillés ; notamment la promotion
logicielle au sein d'une automatisation complète de déploiement d'une
infrastructure,
* à Michael \textsc{Lachand} pour nos discussions sur **l'importance de
l'individu** au sein du domaine professionnel plutôt que des chiffres et des
compétences seules ; mais aussi des difficultés apportés par notre Société
moderne à ce sujet,
* et enfin à Philippe \textsc{Risser-Maroix} avec qui j'ai pu discuter de
**notions informatiques poussées** et de Logiciel Libre sans me sentir seul à
ce sujet ; sa sensibilité au sujet de la **sécurité informatique** est un
point fort !
## Et les autres
D'autres personnes n'ayant aucun lien avec cette formation ont pourtant participé à leur façon. Je tiens à remercier notamment Grégoire \textsc{Stein}, en sa qualité de DevSecOps, pour ses précieux conseils tout au long de cette aventure !
D'autres personnes n'ayant aucun lien avec cette formation ont pourtant
participé à leur façon. Je tiens à remercier notamment Grégoire
\textsc{Stein}, en sa qualité de **DevSecOps**, pour ses **précieux
conseils** tout au long de cette aventure !
Si d'aventures j'aurais oublié des personnes, je m'en excuse. Il y a pourtant ici toute la place nécessaire, voilà pourquoi j'ai reservé ce paragraphe à toutes celles et ceux dont j'aurais omi le nom/prénom.
Si d'aventures j'avais oublié des personnes, je m'en excuse. Il y a pourtant
ici toute la place nécessaire, voilà pourquoi j'ai reservé ce paragraphe à
toutes celles et ceux dont j'aurais omis le nom/prénom.

51
content/10_liste_competences.md
View File

@ -2,42 +2,57 @@
# Liste de compétences couvertes par le projet
Le référentiel de compétences du *Titre Professionnel Administrateur Système DevOps* liste 11 compétences réparties en 3 catégories :
Le référentiel de compétences du *Titre Professionnel Administrateur Système
DevOps* liste 11 compétences réparties en 3 catégories :
* Automatiser le déploiement d’une infrastructure dans le
cloud
* Compétence **n°1 : Automatiser la création de serveurs à l’aide de scripts**
* Automatiser le déploiement d’une infrastructure dans le cloud
* Compétence **n°1 : Automatiser la création de serveurs à l’aide de
scripts**
* Compétence **n°2 : Automatiser le déploiement d'une infrastructure**
* Compétence **n°3 : Sécuriser l’infrastructure**
* Compétence **n°4 : Mettre l’infrastructure en production dans le cloud**
* Compétence **n°4 : Mettre l’infrastructure en production dans le
cloud**
* Déployer en continu une application
* Compétence **n°5 : Préparer un environnement de test**
* Compétence **n°6 : Gérer le stockage des données**
* Compétence **n°7 : Gérer des containers**
* Compétence **n°8 : Automatiser la mise en production d’une application avec une plateforme**
* Compétence **n°8 : Automatiser la mise en production d’une
application avec une plateforme**
* Superviser les services déployés
* Compétence **n°9 : Définir et mettre en place des statistiques de services**
* Compétence **n°9 : Définir et mettre en place des statistiques de
services**
* Compétence **n°10 : Exploiter une solution de supervision**
* Compétence **n°11 : Échanger sur des réseaux professionnels éventuellement en anglais**
* Compétence **n°11 : Échanger sur des réseaux professionnels
éventuellement en anglais**
En utilisant les critères de performance fournis par chaque fiche de compétence, nous avons pu établir le tableau suivant :
En utilisant les critères de performance fournis par chaque fiche de
compétence, j'ai pu établir le tableau suivant :
: Couverture de compétences par le projet
: Couverture de compétences du projet
Compétence | Nbre critères perf. | Couverte ? | Note
-----|:-----:|-----:|:-----
Compétence n°1 | 3/3 | Oui | EC2 / Terraform
Compétence n°2 | 3/3 | Oui | Terraform
Compétence n°3 | 2/2 | Oui | Staging, Vaultwarden, Let's Encrypt
Compétence n°4 | 2/3 | Oui | Terraform → « prod »
Compétence n°4 | **2**/3 | Oui | Terraform → « prod »
Compétence n°5 | 4/4 | Oui | Gitlab CI
Compétence n°6 | 1/3 | Non | postgresql-ha, Velero
Compétence n°6 | **1**/3 | Partiellement | postgresql-ha, Velero
Compétence n°7 | 4/4 | Oui | Docker
Compétence n°8 | 3/4 | Oui | Gitlab CI, Terraform, staging/prod
Compétence n°9 | 0/3 | Non | Aucun interlocuteur
Compétence n°10 | 1/3 | Non | Datadog
Compétence n°8 | **3**/4 | Oui | Gitlab CI, Terraform, staging/prod
Compétence n°9 | **0**/3 | Non | Aucun interlocuteur
Compétence n°10 | **1**/3 | Partiellement | Datadog
Compétence n°11 | 3/3 | Oui | Tout au long du projet
La couverture de la compétence n°6 (Gérer le stockage de données) manque de tests concernant le système de sauvegarde qui a été développé mais pas déployé, faute de tests et de temps. \
La compétence n°9 (Définir et mettre en place des statistiques de services) ne semble pas pertinente dans un projet où nous n'avons eu aucun autre interlocuteur que le « mentor ». \
La compétence n°10 (Exploiter une solution de supervision) est en lien avec la compétence précédente, ce qui influe sur la pertinence des moniteurs mis en place dans la solution. Ce qui, à mon sens, ne résoud pas totalement cette compétence.
La couverture de la **compétence n°6** (Gérer le stockage de données) manque de
tests concernant le système de sauvegarde qui a été développé mais pas
déployé, **faute de tests et de temps**.
La **compétence n°9** (Définir et mettre en place des statistiques de
services) ne semble pas pertinente dans un projet où nous n'avons eu **aucun
autre interlocuteur que le « mentor »**.
La **compétence n°10** (Exploiter une solution de supervision) est **en lien
avec la compétence précédente**, ce qui influe sur la pertinence des moniteurs
mis en place dans la solution. Ce qui, à mon sens, ne résoud pas totalement
cette compétence.

372
content/20_cahier_des_charges.md
View File

@ -2,36 +2,49 @@
# 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.
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.
## Contexte
Commençons par le contexte du projet avec l'ensemble des intervenants et des
contraintes attenantes.
### 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.
**[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 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.
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**.
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](#datascientest).
Ses membres sont, par ordre alphabétique (prénom) :
* Eliel MONCADA
* Hrubech HOMBESSA
* Julien SABIOLS
* **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 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
@ -39,232 +52,315 @@ Pour s'organiser, l'équipe s'est doté de plusieurs outils et suivi quelques m
#### 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.
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).
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 :
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 !
* 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écisifs 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.
* Une boîte courriel, **<team@devu42.fr>** partagée pour la **gestion des
services**,
* [**Groupe DevU42 sur Gitlab**](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 sur
Gitlab](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;:
Deux principales contraintes initiales avaient été imposées dans le cadre de
la formation&nbsp;:
* le budget,
* le temps.
* 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).
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.
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**.
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).
Au terme des 7 semaines, un support visuel de présentation du projet pour son
lancement est attendu (Cf. [Section du présent chapitre sur les
Livrables](#livrables)).
Après livraison, l’amélioration du projet est possible, bien qu'un dossier
professionnel, un dossier de projet (ci-présent) et un support de présentation
est demandé à chacun des [membres de l'équipe DevU42](#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.
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.
L'école de formation [DataScientest](#datascientest) s'évertue à 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;:
On imagine facilement le cadre&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.
> 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;:
De la même manière, l'entreprise pourrait rencontrer 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,
* **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**&nbsp;; 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.
* Manque de **portabilité de l'application** d'un système à l'autre,
* Lenteurs d’implémentation de **nouvelles fonctionnalités** avec
interruptions de service.
Pour bien saisir l'état des lieux de ladite application, regardons de plus près.
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 :
L'**application FastAPI-Træfik** est fournie avec les éléments principaux
suivants&nbsp;:
* 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).
* Backend utilisant le framework **FastAPI** (en Python),
* Frontend statique (en **React**, **Vite.js** et **Chakra UI**)&nbsp;:
Interface de gestion et d'enregistrement d’utilisateurs utilisant l'API du
backend,
* 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.
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.
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.
**Une procédure manuelle existe** pour expliquer comment mettre l'application
en production sur une machine serveur dédiée.
Mais le projet voit plus loin.
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.
* 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** (Amazon Web Services),
* 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.
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.
* 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.
Ce sont des **objectifs plutôt ambitieux pour un temps aussi court**. Un
travail d'équipe et une organisation de cette dernière sont totalement
primordiaux.
## 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.
C'est par le [mentor](#mentor) que nous avons reçu le plan d'action pour les 7
semaines de travail à venir 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.
Commençons par le détail de chaque étape. Pour les 7 semaines à venir.
#### Semaine 1&nbsp;: Cadrage
Sous le signe de l'encadrement, cette première semaine est dite « douce »&nbsp;:
Sous le signe de l'**encadrement**, cette première semaine est dite « douce »&nbsp;:
* réunion de prise de contact, présentation et cadrage,
* **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.
* **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;:
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.
* **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.
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.
* une **configuration de Gitlab**, des principaux dépôts, 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;:
Une fois les outils principaux mis en place, il s'agit d'**automatiser**
plusieurs parties&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).
* 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 d'images**,
* 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 sur
des registres d'images**,
* 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.
L'**adoption d'un workflow Git** pour la gestion des branches est la bienvenue.
#### Semaine 4&nbsp;: Conception de l’infrastructure
Vient ensuite la création de la couche basse de l'infrastructure&nbsp;:
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.
* **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.
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;:
Possiblement en parallèle du [sujet de la semaine 6 sur l'Observabilité et des
alertes](#semaine6), la gestion des données est importante et 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.
* 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/configurer une solution de **sauvegarde** et de **restauration
de données**.
Rien de très particulier à ce niveau là.
C'est un sujet bien à part. D'où la possibilité de la **faire en parallèle**
d'un autre.
#### Semaine 6&nbsp;: Observabilité et alertes
#### Semaine 6&nbsp;: Observabilité et alertes {#semaine6}
Quant à la semaine 6, nous avons principalement la supervision à gérer&nbsp;:
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.
* 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.
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;:
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,
* 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.
C'est un **plan ambitieux** quand on considère que **les membres de l'équipe
proviennent d'horizons et de formations variées**.
### Livrables
### Livrables {#livrables}
Sont attendus les éléments suivants&nbsp;:
Sont attendus les **livrables** 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.
* 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.
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.
En groupe, c'est un projet idéal pour suivre l'« **apprentissage par la
pratique** » proposé par [DataScientest](#datascientest) et couvrir un maximum
de compétences demandées pour le *Titre Professionnel d'Administrateur
Système* DevOps.

306
content/30_specifications_techniques.md
View File

File diff suppressed because one or more lines are too long

272
content/40_demarche.md
View File

@ -3,54 +3,69 @@
# Démarche suivie {#demarche}
La réalisation de ce projet va plus loin que la simple mise en place d'une
application dans le Cloud. C'est une nouvelle équipe, dans un nouvel
environnement avec une application inconnue et des savoirs à acquérir.
application dans le Cloud. C'est une **nouvelle équipe**, dans un **nouvel
environnement** avec une application inconnue et **des savoirs à acquérir**.
En pareille situation, c'est tout un **écosystème DevOps** qu'il faut mettre
en place. Nous allons donc avant tout parler de méthodologie utilisés pour
ce faire, puis des outils utilisés et enfin aborder le sujet de
collaborations avec d'autres équipes.
en place. Nous allons donc avant tout parler de **méthodologie utilisées**
pour ce faire, puis des **outils utilisés** et enfin aborder le sujet de
**collaborations** avec d'autres équipes.
## Méthodologie
### Agile
Le choix d'une méthodologie agile « basique » s'est offerte à nous, notamment par&nbsp;:
Le choix d'une **méthodologie agile** « basique » s'est offerte à nous,
notamment par&nbsp;:
* des **comptes-rendus journaliers rapides de 10mn** en respectant les points suivants&nbsp;:
* des **comptes-rendus journaliers rapides de 10mn** en respectant les points
suivants&nbsp;:
* ce que j'ai fais hier,
* ai-je rencontré un/des problème(s) qui vaille(nt) d'être cité(s),
* ce que je compte faire aujourd'hui,
* la **création de jalons** avec un ensemble de tâches sur une période d'une semaine,
* des échanges réguliers en **pair-programming** sur des sujets difficiles **via [la plateforme Slack](slack.com)**,
* et l'utilisation d'un **tableau façon Kanban** (méthode de gestion de production en flux tendus).
* la **création de jalons** avec un ensemble de tâches sur une période d'une
semaine,
* des échanges réguliers en **pair-programming** sur des sujets difficiles
**via [la plateforme Slack](slack.com)**,
* et l'utilisation d'un **tableau façon Kanban** (méthode de gestion de
production en flux tendus).
C'est ainsi que les jalons ont parsemés la durée du projet en objectifs à atteindre.
C'est ainsi que les **jalons** ont parsemés la durée du projet en **objectifs à
atteindre**.
### Jalons
Les jalons (milestones en anglais) permettent de savoir si le projet dérive de l'objectif attendu. Voici les jalons qui ont été utilisés&nbsp;:
Les **jalons** (milestones en anglais) permettent de savoir si le projet
dérive de l'objectif attendu. Voici les jalons qui ont été utilisés&nbsp;:
* Étape 1 : préparation - outils (config. gitlab, projets, wiki, etc.), **cahier des charges**
* Étape 2 (avec 3) : **CI/CD** sur le projet principal
* Étape 3 (avec 2) : **Infrastructure** (Terraform)
* Étape 4 (avec 5) : Données (**postgreSQL**)
* Étape 5 (avec 4) : **Observabilité**
* Étape 6 : **extras** (s'il y a du temps restant)
* Étape 1 : **préparation** - outils (configuration de gitlab, des projets, du
wiki, etc.), **cahier des charges**,
* Étape 2 (avec 3) : **CI/CD** sur le projet principal,
* Étape 3 (avec 2) : **Infrastructure** (Terraform),
* Étape 4 (avec 5) : Données (**postgreSQL**),
* Étape 5 (avec 4) : **Supervision** (observabilité, alertes),
* Étape 6 : **extras** (s'il reste du temps).
Les jalons n'étaient pas suffisants, d'autres éléments ont dû être pris en compte.
Les jalons n'étaient pas suffisants, d'autres éléments ont dû être pris en
compte.
### Choix de standards et normes
Plusieurs standards/normes ont été choisies pour rassembler plutôt que diviser le groupe&nbsp;: SemVer, Git OneFlow et Conventional commit.
Plusieurs standards/normes ont été choisies pour **rassembler plutôt que
diviser le groupe**&nbsp;: SemVer, Git OneFlow et Conventional commit.
#### SemVer
[SemVer](https://semver.org/) ou **Semantic Versioning** est un standard visant à codifier la manière d'écrire le numéro de version d'une application et leur hiérarchisation (c'est à dire la façon dont on incrémente un numéro de version).
[SemVer](https://semver.org/) ou **Semantic Versioning** est un standard
visant à codifier la manière d'écrire le numéro de version d'une application
et leur hiérarchisation (c'est à dire la façon dont on incrémente un numéro de
version).
Respecter SemVer, c'est permettre d'utiliser des outils conçus pour cela mais aussi et surtout **faciliter la gestion des dépendances**.
Respecter SemVer, c'est permettre d'utiliser des outils conçus pour cela mais
aussi et surtout **faciliter la gestion des dépendances**.
Nous ne détaillerons pas l'ensemble du standard, mais voici quelques exemples de versions&nbsp;:
Nous ne détaillerons pas l'ensemble du standard, mais voici **quelques
exemples de versions**&nbsp;:
```
1.0.0
@ -60,24 +75,38 @@ Nous ne détaillerons pas l'ensemble du standard, mais voici quelques exemples d
1.5.2-rc.2
```
Cela fonctionne donc sous la forme `Majeur`.`Mineur`.`Correctif`.
Cela fonctionne donc sous la forme **Majeur**.*Mineur*.`Correctif`.
#### Git OneFlow
[Git OneFlow](https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow) est un workflow Git conçu par Adam Ruka en alternative à [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/).
[**Git OneFlow**](
https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow) est
un workflow Git conçu par Adam Ruka en alternative à [GitFlow](
https://nvie.com/posts/a-successful-git-branching-model/).
Il se base principalement sur un objectif simple&nbsp;: avoir un arbre Git dont la **branche principale** est **la plus linéaire possible**. C'est à dire avec le moins d'embranchements possibles.
Il se base principalement sur un objectif simple&nbsp;: avoir un arbre Git
dont la **branche principale** est **la plus linéaire possible**. C'est à dire
avec le moins d'embranchements possibles.
En somme on va favoriser le **rebase** sur les branches dédiées à une nouvelle fonctionnalité AVANT de fusionner sur la branche principale. Cela aura l'avantage&nbsp;:
En somme on va favoriser le **rebase** sur les branches dédiées à une nouvelle
fonctionnalité **avant de fusionner sur la branche principale**. Cela aura
l'avantage&nbsp;:
* de réduire le travail de la personne qui fusionne la branche de fonctionnalités,
* et de favoriser la résolution des conflits de fusion aux développeurs responsables de la branche de fonctionnalités.
* de réduire le travail de la personne qui fusionne la branche de
fonctionnalités,
* et de favoriser la résolution des conflits de fusion aux développeurs
responsables de la branche de fonctionnalités.
![Avant/après la fusion d'une branche en utilisant Git OneFlow](./media/feature-branch-rebase-final.png){width=50%}\
![Avant/après la fusion d'une branche en utilisant Git
OneFlow](./media/feature-branch-rebase-final.png){width=50%}
\newpage
#### Conventional commit
Dans le cadre de la rédaction de message de commit pour chaque changement effectué sur un dépôt, nous avons choisi de suivre la spécification [Commits Conventionnels](https://www.conventionalcommits.org/fr/v1.0.0/#r%C3%A9sum%C3%A9).
Dans le cadre de la **rédaction de message de commit** pour chaque changement
effectué sur un dépôt, nous avons choisi de suivre la **spécification [Commits
Conventionnels](https://www.conventionalcommits.org/fr/v1.0.0/#r%C3%A9sum%C3%A9)**.
Cela se résume à peu près à cela&nbsp;:
@ -89,7 +118,7 @@ Cela se résume à peu près à cela&nbsp;:
[pied optionnel]
```
Qui donne par exemple&nbsp;:
Qui donne **par exemple**&nbsp;:
```markdown {.numberLines}
feat(backend): include postgreSQL BDD + backend
@ -107,111 +136,180 @@ feat(backend): include postgreSQL BDD + backend
ref projet#18
```
On notera aussi l'**usage des références Gitlab** en fin de message de commit
pour **faire un lien entre le commit et un ticket spécifique**, en l'occurence
l'exemple montre une référence vers le ticket #18 du dépôt nommé *projet*.
## Outils
Au delà d'une à plusieurs méthodologies/normes/standards, nous avons utilisés des outils afférents.
Au delà d'une à plusieurs méthodologies/normes/standards, nous avons utilisés
des outils afférents.
### Nom de domaine
Afin d'avoir une **boîte courriel commune** (team@devu42.fr) et des **noms de domaine** qui pointent sur le résultat de nos travaux, nous avons opté pour la location d'un nom de domaine&nbsp;: **devu42.fr**.
Afin d'avoir une **boîte courriel commune** (team@devu42.fr) et des **noms de
domaine** qui pointent sur le résultat de nos travaux, nous avons opté pour la
location d'un nom de domaine&nbsp;: **devu42.fr**.
Ce domaine fait référence à notre cursus de DevOps dans un centre de formation nommé **DevU**niversity. Le nombre 42 est un chiffre connu lié aux ouvrages de Douglas Adams dans sa trilogie en 5 volumes de « H2G2, Guide du Voyageur Galactique ».
Ce domaine fait référence à notre cursus de DevOps dans un centre de formation
nommé **DevU**niversity. Le **nombre 42** est un chiffre connu lié aux
ouvrages de Douglas Adams dans sa trilogie en 5 volumes de « H2G2, Guide du
Voyageur Galactique ».
Nous avons ainsi pu avoir des noms de domaines spécifiques pour&nbsp;:
Nous avons ainsi pu avoir des **noms de domaines spécifiques** pour&nbsp;:
* le backend (API) dans l'environnement de pré-production,
* le backend (API) dans l'environnement de production,
* le frontend dans l'environnement de pré-production,
* et le frontend dans l'environnement de production.
* le backend (API) dans l'environnement de pré-production,
**api.staging**.devu42.fr,
* le backend (API) dans l'environnement de production, **api.r53**.devu42.fr,
* le frontend dans l'environnement de pré-production,
**www.staging**.devu42.fr,
* et le frontend dans l'environnement de production, **www.r53**.devu42.fr.
C'était donc un bon départ.
### Plateforme DevOps
Notre outils principal a été la **plateforme Gitlab**. C'est une plateforme complète de DevOps qui couvre bon nombre de besoins DevOps parmi&nbsp;:
Notre outil principal a été la **plateforme Gitlab**. C'est une plateforme
complète de DevOps qui couvre bon nombre de besoins DevOps parmi&nbsp;:
* des dépôts de code source (dépôts Git),
* un système d'intégration continu (GitlabCI),
* une gestion des rôles utilisateurs pour une granularité de gestion de permissions tout en finesse,
* des dépôts pour&nbsp;:
* les Chart Helm,
* les images Docker,
* les modules Terraform,
* les états Terraform,
* les librairies Python, PHP, JS,
* des dépôts de code source (**dépôts Git**),
* un système d'**intégration continue** (**GitlabCI**),
* une gestion des **rôles utilisateurs** pour une granularité de **gestion de
permissions** tout en finesse,
* des dépôts/**registres** pour&nbsp;:
* les **Chart Helm**,
* les **images Docker**,
* les **modules Terraform**,
* les **états Terraform**,
* les bibliothèques Python, PHP, JS,
* etc.,
* un système de gestion de tickets pour le retour régulier (feedback) des utilisateurs,
* l'usage de jalons, kanban et métriques des équipes pour une gestion efficace d'une à plusieurs équipe dans un projet,
* la gestion des versions (release),
* l'intégration avec Kubernetes pour un suivi depuis Gitlab de nos clusters Kubernetes,
* un **système de gestion de tickets** pour le retour régulier (feedback) des
utilisateurs,
* l'usage de **jalons**, **kanban** et **métriques des équipes** pour une
gestion efficace d'**une à plusieurs équipes** dans un projet,
* la gestion des versions (**releases**),
* l'**intégration avec Kubernetes** pour un suivi depuis Gitlab de nos
clusters Kubernetes,
* etc.
De nombreuses fonctionnalités supplémentaires existent dans Gitlab. Cela en fait donc un outil de choix pour notre projet.
De nombreuses fonctionnalités supplémentaires existent dans Gitlab. Cela en
fait donc un outil de choix pour notre projet.
\newpage
#### Base de connaissance
Une des premières choses qui a été faite sur cette plateforme a été la **mise en place d'une base de connaissances** sous la forme d'un Wiki.
Une des premières choses qui a été faite sur cette plateforme a été la **mise
en place d'une base de connaissances** sous la forme d'un Wiki.
Pour plusieurs raisons&nbsp;:
* partager nos découvertes sur les outils (liens web, procédures d'installation, etc.),
* détailler nos diverses installations,
* partager nos travaux,
* rédaction de contenu concernant les réunions, des outils, etc.
* **partager nos découvertes** sur les outils (liens web, procédures
d'installation, etc.),
* détailler nos diverses **installations**,
* **partager nos travaux**,
* rédaction de contenu concernant les **réunions**, des **outils**, etc.
![Impression écran de la page d'accueil du Wiki](./media/screenshot_wiki_projet.png){width=100%}\
![Impression écran de la page d'accueil du
Wiki](./media/screenshot_wiki_projet.png){width=100%}
\newpage
#### Workflow des tickets
Autre exemple de configuration de la plateforme Gitlab afin de suivre notre organisation&nbsp;: la création d'un workflow de l'état d'un ticket, que vous trouverez ci-après.
Autre exemple de configuration de la plateforme Gitlab afin de suivre notre
organisation&nbsp;: la **création d'un workflow de l'état d'un ticket**, que
vous trouverez ci-après.
![Schéma du workflow de l'état des tickets](./media/schema_workflow_ticket.png){width=50%}\
![Schéma du workflow de l'état des
tickets](./media/schema_workflow_ticket.png){height=70%}
Il permet à chaque membre de l'équipe de prendre connaissance des habitudes en matière de gestion de ticket.
Il permet à chaque membre de l'équipe de prendre connaissance des habitudes en
matière de gestion de ticket.
Il est utile si jamais nous changerions de plateforme DevOps&nbsp;: il suffirait d'appliquer à nouveau le même workflow.
Il est utile si jamais nous changions de plateforme DevOps&nbsp;: il suffirait
d'appliquer à nouveau le même workflow.
## Cas d'une collaboration inter-équipe {#collab}
Dans le cadre de nos diverses **réflexions** nous avons eu un contact **avec l'équipe** qui se nomme **« Team Matrix »** dont le sujet était le déploiement de serveurs Matrix en haute disponibilité.
Dans le cadre de nos diverses **réflexions** nous avons eu un contact **avec
l'équipe** qui se nomme **« Team Matrix »** dont le sujet était le déploiement
de serveurs Matrix en haute disponibilité.
Nous avons échangé sur le sujet de la promotion des versions entre environnements. Maxime, de la Team Matrix, et moi avons principalement discuté autour de l'article suivant&nbsp;: [How to model your GitOps environments and promote releases between them](https://codefresh.io/blog/how-to-model-your-gitops-environments-and-promote-releases-between-them/).
Nous avons échangé sur le **sujet de la promotion des versions entre
environnements**. Maxime, de la Team Matrix, et moi avons principalement
discuté autour de l'article suivant&nbsp;: [How to model your GitOps
environments and promote releases between them](
https://codefresh.io/blog/how-to-model-your-gitops-environments-and-promote-releases-between-them/)
(
https://codefresh.io/blog/how-to-model-your-gitops-environments-and-promote-releases-between-them/
).
L'idée de l'article, en quelques mots, est de **favoriser l'utilisation d'un dossier par environnement** plutôt qu'utiliser une branche Git pour chaque environnement. Il ajoute également de faire la promotion des versions entre ces différents environnements/dossiers. Avec une procédure « humaine » pour limiter de trop nombreuses promotions.
L'idée de l'article, en quelques mots, est de **favoriser l'utilisation d'un
dossier par environnement** plutôt qu'utiliser une branche Git pour chaque
environnement. Il conseille également de faire la promotion des versions entre
ces différents environnements/dossiers. Avec un protocole à suivre par les «
humains » pour limiter de trop nombreuses promotions logicielles en même temps.
Pour reprendre le schéma de l'article&nbsp;:
![Schéma extrait de l'article sur la promotion des versions](./media/article_schema_promotion.png){width=100%}\
![Schéma extrait de l'article sur la promotion des
versions](./media/article_schema_promotion.png){width=100%}
Après moultes discussions, nous sommes tombés d'accord sur quelques points, parmi&nbsp;:
Après moultes discussions, **nous sommes tombés d'accord** sur quelques
points, parmi&nbsp;:
* ne PAS utiliser une branche par environnement,
* essayer au maximum d'avoir des dépôts indépendants (favoriser la modularité),
* faire de la promotion logicielle par la CI plutôt que manuellement,
* et utiliser les particularités des outils que nous avons (Terragrunt dans le cas de Maxime).
* **ne pas utiliser une branche par environnement**,
* essayer au maximum d'**avoir des dépôts indépendants** (favoriser la
modularité),
* favoriser la **promotion logicielle par la CI** plutôt que manuellement,
* et **utiliser les particularités des outils que nous avons** (Terragrunt
dans le cas de Maxime).
Notre réflexion a evolué suite à ces échanges. Et nous avons opté initialement pour utiliser un dossier par environnement dans un dépôt unique nommé **infra**. Puis nous avons adapté notre intégration continue pour copier les valeurs communes de l'environnement de pré-production (staging) vers l'environnement de production (prod).
Notre réflexion a **evolué suite à ces échanges**. Et nous avons opté
initialement pour utiliser **un dossier par environnement dans un dépôt
unique** nommé **infra**. Puis nous avons adapté notre intégration continue
pour copier les valeurs communes de l'environnement de pré-production
(staging) vers l'environnement de production (prod).
Mon idéal serait&nbsp;:
**Mon idéal** serait&nbsp;:
* avoir des dépôts indépendants pour chaque application avec des tests de sécurité, des tests du code, vérification de la couverture de code et tests sur la compilation - éventuelle - de l'outil et/ou des images Docker puis publication sur un registre,
* avoir une gestion de chacun de ces dépôts d'un système de versionnement (les fameuses « releases »),
* avoir la même chose pour chaque module Terraform que nous avons fabriqué (par exemple notre module « networking »),
* puis utiliser, dans un dépôt **infra** par exemple, nos modules situés sur des registres avec une version donnée,
* avoir des **dépôts indépendants pour chaque application** avec des **tests
de sécurité**, des **tests du code**, vérification de la **couverture de
code** et **tests sur la compilation** - éventuelle - de l'outil et/ou des
**images Docker** puis **publication sur un registre**,
* avoir une gestion de chacun de ces dépôts d'**un système de versionnement**
(les fameuses « releases »),
* avoir la **même chose pour chaque module Terraform** que nous avons fabriqué
(par exemple notre module « networking »),
* puis utiliser, dans un dépôt **infra** par exemple, seulement les versions
de nos modules (situés indépendamment sur des registres),
* de là on peut imaginer&nbsp;:
* soit de la promotion des versions par une intégration continue entre dépôts (pré-production vers production par exemple) OU entre dossiers représentant un environnement,
* soit de la promotion des versions par une validation manuelle entre la pré-production et la production,
* ajouter des tests de sécurité des images (comme le contrôle de somme) avant utilisation dans d'autres dépôts.
* soit de la promotion des versions par une intégration continue entre
dépôts (pré-production vers production par exemple) OU entre dossiers
représentant un environnement,
* soit de la promotion des versions par une validation manuelle entre la
pré-production et la production,
* ajouter des **tests de sécurité des images** (comme la somme de contrôle) avant
utilisation dans d'autres dépôts.
À noter que Maxime et moi étions également arrivés sur le fait qu'il y a déjà 2 types de promotions dans tout cela&nbsp;:
À noter que Maxime et moi étions également arrivés sur le fait qu'il y a déjà
2 types de promotions dans tout cela&nbsp;:
* la promotion des versions des logiciels/modules/charts utilisés,
* et la promotion des configurations de ces derniers au sein de nos infrastructures.
* et la promotion des configurations de ces derniers au sein de nos
infrastructures.
C'est un autre sujet très intéressant que nous ne détaillerons pas ici.
## Conclusion
La démarche entreprise a été structurée autour de méthodologies et d'outils et nous a permis de faire avancer le projet. L'apport des discussions autour de la promotion logiciel avec une autre équipe a eu un impact conséquent sur nos choix concernant l'automatisation et le déploiement continu sur l'environnement de pré-production. Nous en parlerons d'ailleurs dans le prochain chapitre un peu plus en détail.
La **démarche entreprise** a été structurée autour de **méthodologies** et
d'**outils** et nous a permis de faire avancer le projet. L'apport des
**discussions autour de la promotion logicielle** avec une autre équipe a eu
un impact conséquent sur nos choix concernant l'automatisation et le
déploiement continu sur l'environnement de pré-production. Nous en parlerons
d'ailleurs dans le prochain chapitre un peu plus en détail.
Cependant la gestion d'équipe lors de ce projet a fait défaut et nous aurions pu nous organiser bien mieux qu'il n'a été.
A contrario, la **gestion d'équipe** lors de ce projet **a fait défaut** et
nous aurions pu nous organiser bien mieux qu'il n'a été.

293
content/50_realisations.md
View File

File diff suppressed because one or more lines are too long

161
content/60_situation_de_travail.md
View File

File diff suppressed because one or more lines are too long

20
content/80_conclusion.md
View File

@ -2,10 +2,22 @@
# Conclusion
Ma passion anticipée pour l'automatisation et l'amélioration des processus de création logiciel m'ont amené à ce moment, aujourd'hui, où j'écris ces lignes pour embrasser le métier d'Administrateur Système DevOps. La formation, puis le projet de fin de formation ont été bénéfique à la prise d'expérience, mais pas que.
Ma **passion anticipée pour l'automatisation** et l'**amélioration des
processus** de **création logiciel** m'ont amené à ce moment, aujourd'hui, où
j'écris ces lignes pour **embrasser le métier d'Administrateur Système
DevOps**. La formation, puis **le projet de fin de formation** ont été
**bénéfique à la prise d'expérience**, mais pas que.
En effet il est question de nouvelles compétences que le projet, à travers la rédaction d'un cahier des charges, de spécifications fonctionnelles, d'une approche (démarche) suivie, de plusieurs réalisations et de situations diverses qu'ont permis d'acquérir tout au long de ces derniers mois.
En effet, **il est question de nouvelles compétences**, que le projet, à
travers la rédaction d'un cahier des charges, de spécifications
fonctionnelles, d'une approche (démarche) suivie, de plusieurs réalisations et
de situations diverses, a permis d'**acquérir tout au long de ces derniers
mois**.
Ainsi je ressors riche de nouvelles expériences, de nouveaux outils, de nouvelles méthodes et de nouveaux collaborateurs dans un monde sans cesse grandissant qu'est le monde du DevOps.
Ainsi **je ressors riche de nouvelles expériences**, de **nouveaux outils**,
de **nouvelles méthodes** et de **nouveaux collaborateurs** dans un monde sans
cesse grandissant qu'est **le monde du DevOps**.
Bien que ne sachant ce que l'avenir me réserve, j'espère qu'il continuera sur la voie du DevOps et de l'enrichissement par de nouvelles connaissances et perspéctives professionnelles d'avenir&nbsp;!
Bien que ne sachant ce que l'avenir me réserve, j'espère qu'il continuera sur
la voie du DevOps et de l'enrichissement par de nouvelles connaissances et
perspéctives professionnelles d'avenir&nbsp;!

BIN
media/screenshot_fluxcd-doc.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 198 KiB

BIN
media/screenshot_fluxcd_doc.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 183 KiB

1
templates/default.latex
View File

@ -173,6 +173,7 @@ $if(colorlinks)$
\usepackage{xcolor}
$endif$
\usepackage{hyperref}
\usepackage{rotating}
\hypersetup{
$if(title-meta)$
pdftitle={$title-meta$},