* É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.
{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).
* 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 : **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 :
* 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 :
* 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 :
* 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.
Autre exemple de configuration de la plateforme Gitlab afin de suivre notre organisation : la création d'un workflow de l'état d'un ticket, que vous trouverez ci-après.
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 : [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.
Pour reprendre le schéma de l'article :
{width=100%}\
Après moultes discussions, nous sommes tombés d'accord sur quelques points, parmi :
* 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).
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 :
* 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,
* de là on peut imaginer :
* 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.
À 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 :
* la promotion des versions des logiciels/modules/charts utilisés,
* et la promotion des configurations de ces derniers au sein de nos infrastructures.
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.
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é.
