chore(content): Specs + démarche - Add more content

content/40_demarche.md

@@ -81,7 +81,7 @@ Dans le cadre de la rédaction de message de commit pour chaque changement effec
 
 Cela se résume à peu près à cela : 
 
-```ini {.numberLines}
+```
 <type>[étendue optionnelle]: <description>
 
 [corps optionnel]
@@ -171,20 +171,45 @@ Il permet à chaque membre de l'équipe de prendre connaissance des habitudes en
 
 Il est utile si jamais nous changerions de plateforme DevOps&nbsp;: il suffirait d'appliquer à nouveau le même workflow.
 
-### Environnements
-
-* Développement : chez chaque DEV (Dockerfile + docker-compose du projet lui-même)
-* Tests : dans chaque gitlab-runner utilisé, via une CI
-* Pré-production (appelé « staging ») : AWS staging
-* Production : AWS production
-
-TODO: donner schéma effectué
-
 ## Cas d'une collaboration inter-équipe
 
-TODO : compléter
+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é.
 
-* réunion avec l'équipe Matrix pour échanger sur nos problématiques principales et nos choix actuels
-* échange au sujet de la promotion logicielle avec l'équipe Matrix (Maxime)
+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/).
 
-TODO : expliquer en quelques lignes que ça a été le cas avec l'équipe Odoo de manière bien plus sporadique (irrégulière)
+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&nbsp;: 
+
+![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;: 
+
+* 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&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,
+* 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.
+
+À 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.
+
+C'est un autre sujet très intéressant que nous ne détaillerons pas ici.
+
+## Conclusion
+
+TODO : conclusion de la démarche