lmasi/webzine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Documentation: relecture, ajout de la conclusion. Dossier de configuration complété.

Browse Source
This commit is contained in:
josephine.vetu
2026-04-09 00:19:46 +02:00
parent c676019040
commit 267a50f053
8 changed files with 170 additions and 132 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
Webzine.Documentation/Rapport/equipe 1 - 4.Problemes techniques.md
View File

@@ -1,4 +1,4 @@
# Rapport d'équipe — Projet Webzine
# Rapport d'équipe - Projet Webzine
**Équipe 1**
**Formation :** Développement .NET niveau 1 / Dr1-P4
@@ -24,12 +24,13 @@ Nous avons pourtant passer en revue chaque PR. Ces corrections ont permis d'amé
C'est probablement le chantier le plus difficile du jalon 2. Au jalon 1, les données étaient instanciées directement dans les controllers via des classes factory. Ça fonctionnait pour afficher les vues, mais tout était couplé : il était impossible de connecter une vraie base de données sans tout réécrire.
La migration vers des repositories a impliqué plusieurs changements simultanés :
- extraire la logique de données,
- créer des interfaces,
- reconfigurer `Program.cs` pour gérer l'injection de dépendances.
La migration vers des repositories a impliqué plusieurs changements simultanés :
Cette dernière partie a été la plus difficile à appréhender — les cycles de vie des services (`Singleton`, `Scoped`, `Transient`) et la façon dont ASP.NET Core résout les dépendances à l'exécution n'étaient pas évidents au départ.
- extraire la logique de données,
- créer des interfaces,
- reconfigurer `Program.cs` pour gérer l'injection de dépendances.
Cette dernière partie a été la plus difficile à appréhender - les cycles de vie des services (`Singleton`, `Scoped`, `Transient`) et la façon dont ASP.NET Core résout les dépendances à l'exécution n'étaient pas évidents au départ.
La coexistence de deux environnements (SQLite en dev, PostgreSQL en prod) a ajouté une couche de complexité supplémentaire : il fallait deux implémentations concrètes des mêmes interfaces et conditionner leur enregistrement dans `Program.cs` selon l'environnement.
@@ -64,9 +65,3 @@ Ce type d'erreur arrive quand les responsabilités des différentes couches ne s
La CI/CD mise en place par Clément et Mathys teste tous les endpoints de l'application et mesure leurs temps d'exécution. C'est un choix pertinent pour surveiller les performances, mais lors de sa mise en place initiale, chaque exécution du pipeline rendait Gitea inutilisable pendant une dizaine de secondes.
Pour une équipe dont tout le code et tous les tickets reposent sur cette instance, c'était bloquant. Le problème venait du fait que les dépendances étaient retéléchargées à chaque run. Les mettre en cache a résolu le problème.
C'est une pratique standard de CI/CD que nous aurions dû anticiper. Plus globalement, faire tourner le runner CI/CD sur la même machine que Gitea n'est pas idéal : les ressources sont partagées, et un pipeline gourmand peut dégrader l'ensemble des services.
### L'incident HTTPS sur Gitea
Le 25 mars, le passage de Gitea en HTTPS a causé une perte d'accès temporaire au dépôt, gérée seul par Mathys. Si l'incident a été résolu rapidement, une panne plus longue aurait pu bloquer toute l'équipe. Le fait qu'une seule personne administre l'ensemble de l'infrastructure crée ce type de fragilité.