chore(content): [WIP] - Démarche

content/40_demarche.md

@@ -1,8 +1,6 @@
 \newpage
 
-# Démarche suivie et opportunité(s) de collaboration {#demarche}
-
-TODO: introduction
+# 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 
@@ -11,28 +9,151 @@ 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.
 
-## Démarche et outils
+TODO: détailler le plan
 
-TODO : compléter
+## Méthodologie
 
-Gitlab, Slack, SemVer, Git OneFlow, Conventional commit, différents environnements
+### Agile
 
-* D'abord une plateforme avec un groupe (gitlab.com/devu42) et un projet principal (`projet`) + base de connaissances (wiki)
-* Un domaine devu42.fr pour avoir une adresse courriel (team@devu42.fr) partagée
-* Création d'étapes (jalons) progressives : 
-  * É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 (si on a le temps)
-* Compte-rendus réguliers
+Le choix d'une méthodologie agile « basique » s'est offerte à nous, notamment par : 
 
-### Normes
+* des **comptes-rendus journaliers rapides de 10mn** en respectant les points suivants : 
+  * 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).
 
-* SemVer
-* Git OneFlow
-* Conventional commit
+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 : 
+
+* É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)
+
+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 : 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).
+
+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 : 
+
+```
+1.0.0
+2.1.4
+0.6.3-alpha
+0.6.3-alpha.1
+1.5.2-rc.2
+```
+
+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/).
+
+Il se base principalement sur un objectif simple : 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 : 
+
+* 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%}\
+
+#### 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).
+
+Cela se résume à peu près à cela : 
+
+```
+<type>[étendue optionnelle]: <description>
+
+[corps optionnel]
+
+[pied optionnel]
+```
+
+Qui donne par exemple&nbsp;: 
+
+```
+feat(backend): include postgreSQL BDD + backend
+
+* change EC2 instances to t3.large
+* change min_size nodes to 2
+* use backend version 0.0.1
+* use annotations to have api.r53.devu42.fr as domain for backend + Let's Encrypt with cert-manager
+* update EBS CSI driver to v1.37.0-eksbuild.1
+* declare a StorageClass EBS in gp3 for postgreSQL
+* use this EBS StorageClass in our backend chart for postgreSQL
+* set database size to 1Gi
+
+ref projet#18
+```
+
+## Outils
+
+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**.
+
+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;: 
+
+* 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.
+
+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;: 
+
+* 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,
+  * 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,
+* etc.
+
+De nombreuses fonctionnalités supplémentaires existent dans Gitlab. Cela en fait donc un outil de choix pour notre projet.
+
+#### Workflow des tickets
+
+schéma workflow tickets
+
+#### Base de connaissance
+
+Wiki
 
 ### Environnements
 
@@ -43,22 +164,6 @@ Gitlab, Slack, SemVer, Git OneFlow, Conventional commit, différents environneme
 
 TODO: donner schéma effectué
 
-### Plateforme DevOps
-
-* couvre les principes DevOps
-* Github vs. Gitlab ?
-* services utilisés&nbsp;: 
-  * Tickets
-  * Jalons
-  * Kanbans
-* Base de connaissance collaborative : Wiki sous Gitlab
-
-### Méthodologie
-
-* Méthodologie Agile basique
-* Compte-rendus journaliers
-* Jalon pour chaque semaine, avec quelques tickets par étapes
-
 ## Cas d'une collaboration inter-équipe
 
 TODO : compléter