diff --git a/content/30_specifications_techniques.md b/content/30_specifications_techniques.md index 64d7bc6..1e32cb3 100644 --- a/content/30_specifications_techniques.md +++ b/content/30_specifications_techniques.md @@ -58,7 +58,7 @@ La partie proxy utilise actuellement **Traefik comme outil**. Ce qui n'est pas u Ces trois parties ont une influence sur le choix de l'infrastructure à mettre en place. Il reste cependant une **marge de manœuvre sur la partie proxy**. -## Infrastructure d'accueil +## Infrastructure Afin d'accueillir l'application dans le Cloud, l'infrastructure de base va poser les fondations de l'environnement complet nécessaire à un usage quotidien. @@ -106,6 +106,21 @@ Dans le cluster pourra donc tourner, en plus des agents précédemment cités, l Afin de permettre une livraison régulière de l'application, il va falloir automatiser au maximum les étapes entre la publication d'une nouvelle version de l'application et sa livraison. Puis son déploiement en production via une intervention humaine. +### Environnements + +Nous parlons de production depuis un moment. À quoi cela correspond ? + +Afin de mener à bien le travail de DevOps, nous avons défini les différents environnements par lesquels nous allons passer pour toute notre chaîne de production logicielle. Ainsi nous avons 4 environnements : + +* l'environnement de **développement** : c'est l'environnement disponible sur chaque machine des développeurs à l'aide des outils fournis (Dockerfile, docker-compose du projet applicatif), +* l'environnement de test : il est composé de l'ensemble des Runner Gitlab utilisés à l'intérieur de la chaîne d'intégration continue, +* l'environnement de pré-production (appelé « staging ») : c'est l'infrastructure présentée ci-avant, appliquée dans AWS avec une configuration dite *plus légère* (moins de machines virtuelles EC2 par exemple), +* et l'environnement de production : c'est l'infrastructure finale ; celle qui est disponible aux usagers. + +[//]: # Cf. https://mermaid.live/view#pako:eNptkkFugzAQRa9izRoiAiUkLLrKtlKldtXShYUHYtXY1Nhp05AD5Ry5WAcCUSuVFR6_-X4e-QilEQg5VMp8ljtuHXveFprRJ3D_WvG84mGLtjM6FLKupa7Z9nLeozJtiw1q93alP_gE18gte8Zu3ugcH7qmXSU7F5Y7LN_Zo72cw9Ya4UsnjZ7woTCxpTJeEPaLuJmxMLxnvcCGa4FUYJXvCOnJY_a5Io5MOsa9Mw138sNj189Kf_yu9J4rKfhwGKNkj0phPyrNR8-xl_NwCTam94PQP2FSj3GX8wRAAA3ahktB8z4ODQW4HQ2xgJx-BVbcK1dAoU-EDspPB11C7qzHAKzx9Q5oLqqjlW9JE7eS15Y3M9Jy_WJMc4NoDfkRviCPo2SxSdZplEXrKMrWyziAA5Wz5SJJ0ihebrJ4la7i9BTA9xgRLVZJnCXZJrlL19S6CgCFdMY-XN_L-GxOP_j4v68 + +![Schéma des environnements utilisés](./media/schema_workflow_environnement.png){height=50%}\ + ### Livraison continue et déploiement Il est visé une CI/cd, c'est à dire une Intégration Continue (Continuous Integration) et une livraison continue (continuous delivery). **L'automatisation est donc essentielle.** diff --git a/content/40_demarche.md b/content/40_demarche.md index fe1efd0..9b3959a 100644 --- a/content/40_demarche.md +++ b/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} +``` [étendue optionnelle]: [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 : 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 : [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 : + +![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 : + +* 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. + +C'est un autre sujet très intéressant que nous ne détaillerons pas ici. + +## Conclusion + +TODO : conclusion de la démarche diff --git a/media/article_schema_promotion.png b/media/article_schema_promotion.png new file mode 100644 index 0000000..0e0a7cb Binary files /dev/null and b/media/article_schema_promotion.png differ diff --git a/media/schema_workflow_environnement.png b/media/schema_workflow_environnement.png new file mode 100644 index 0000000..bd7852a Binary files /dev/null and b/media/schema_workflow_environnement.png differ