soutenance/content/40_demarche.md

\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 : 

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

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

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

\newpage

#### 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){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&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/)
(
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&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é),
* 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&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, seulement les versions 
de nos modules (situés indépendamment sur des registres),
* 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 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&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 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é.