soutenance/content/40_demarche.md

\newpage

Démarche suivie

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,
• 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 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 est un workflow Git conçu par Adam Ruka en alternative à GitFlow.

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.

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

Cela se résume à peu près à cela :

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

[corps optionnel]

[pied optionnel]

Qui donne par exemple :

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 + 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 : devu42.fr.

Ce domaine fait référence à notre cursus de DevOps dans un centre de formation nommé DevUniversity. 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,
• 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 :

• 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 :
  • 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.

Workflow des tickets

schéma workflow tickets

Base de connaissance

Wiki

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)