@@ -44,15 +44,15 @@ La stratégie d'utilisation de git découle de l'organisation de l'équipe produ
Sur ce projet, il n'existe que deux types de branches :
* les branches `feature-*`, sur lesquelles les développeurs travaillent au quotidien
* la branche `master`, qui accueille les développement une fois ceux-ci terminés
* la branche `main`, qui accueille les développement une fois ceux-ci terminés
Lors des développements des fonctionnalités et des correctifs, les travaux sont faits sur des branches de fonctionnalités, nommées `feature-*`.
A chaque fois qu'un commit est poussé sur gitlab, la tâche de compilation est lancée.
Pour partager son travail, le développeur crée une `Merge Request` sur gitlab, pour demander à ce que son code soit revu et mergé sur la branche `master`.
Pour partager son travail, le développeur crée une `Merge Request` sur gitlab, pour demander à ce que son code soit revu et mergé sur la branche `main`.
Lors de la création de la `Merge Request` et pour chaque modification de la branche source (`feature-*`) et de la branche cible (`master`), un pipeline est lancé.
Lors de la création de la `Merge Request` et pour chaque modification de la branche source (`feature-*`) et de la branche cible (`main`), un pipeline est lancé.
Ce pipeline lance les tâches de compilation et de tests unitaires sur la version cible du code.
Le schéma ci-dessous illustre le fonctionnement de l'intégration continue au quotidien.
...
...
@@ -69,7 +69,7 @@ Régulièrement, pour contrôler la qualité du code, on lance la tâche `maven
*...
Ce contrôle est planifié via les `scheduled pipelines` : https://gitlab-forge.din.developpement-durable.gouv.fr/help/ci/pipelines/schedules
Il est effectué sur la branche `master` et la dernière version des rapports est publiée sur les "gitlab-pages".
Il est effectué sur la branche `main` et la dernière version des rapports est publiée sur les "gitlab-pages".
Le schéma ci-dessous illustre le fonctionnement de la qualimétrie dans le contexte de l'intégration continue.
...
...
@@ -83,7 +83,7 @@ Les rapports précédents sont exportés sous la forme d'artéfacts et peuvent
### Publication des livrables
Une fois les développements prêts à être déployés, un `tag` est créé sur le dernier commit de la branche `master`.
Une fois les développements prêts à être déployés, un `tag` est créé sur le dernier commit de la branche `main`.
La création de ce `tag`, lance un pipeline, qui contrôle la qualité du code, puis crée et publie deux livrables :
