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.

TODO: détailler le plan

## 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 (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 : 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%}\

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

```ini {.numberLines}
<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.

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

* 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)

TODO : expliquer en quelques lignes que ça a été le cas avec l'équipe Odoo de manière bien plus sporadique (irrégulière)