216 lines
10 KiB
Markdown
216 lines
10 KiB
Markdown
\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.
|
|
|
|
{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 :
|
|
|
|
```
|
|
<type>[étendue optionnelle]: <description>
|
|
|
|
[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
|
|
```
|
|
|
|
## 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,
|
|
* 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.
|
|
|
|
#### 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.
|
|
|
|
{width=100%}\
|
|
|
|
#### 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.
|
|
|
|
{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 : 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/).
|
|
|
|
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 :
|
|
|
|
{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é),
|
|
* 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 :
|
|
|
|
* 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 :
|
|
* 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 :
|
|
|
|
* 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
|
|
|
|
TODO : conclusion de la démarche
|