\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és 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&nbsp;: 

* des **comptes-rendus journaliers rapides de 10mn** en respectant les points suivants&nbsp;: 
  * 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&nbsp;: 

* É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&nbsp;: 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&nbsp;: 

```
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&nbsp;: 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&nbsp;: 

* 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&nbsp;: 

```
<type>[étendue optionnelle]: <description>

[corps optionnel]

[pied optionnel]
```

Qui donne par exemple&nbsp;: 

```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
```

## 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.

#### 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&nbsp;: 

* 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%}\

#### Workflow des tickets

Autre exemple de configuration de la plateforme Gitlab afin de suivre notre organisation&nbsp;: 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){width=50%}\

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 changerions de plateforme DevOps&nbsp;: 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&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/).

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

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é.
