\newpage # 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**. 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é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 : * 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). 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 (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. ### 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%} \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)**. Cela se résume à peu près à cela : ``` [étendue optionnelle]: [corps optionnel] [pied optionnel] ``` Qui donne **par exemple** : ```markdown {.numberLines} 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 * use annotations to use 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 ``` 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. ### 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, **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 outil 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 continue** (**GitlabCI**), * une gestion des **rôles utilisateurs** pour une granularité de **gestion de permissions** tout en finesse, * des dépôts/**registres** pour : * 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 é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. \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. Pour plusieurs raisons : * **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%} \newpage #### Workflow des tickets 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. ![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 est utile si jamais nous changions de plateforme DevOps : 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é. 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/) ( 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 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 : ![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é), * 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). **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, seulement les versions de nos modules (situés indépendamment sur des registres), * 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 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 : * 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 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. 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é.