sam
e5e6f72f92
- CI/CD Gitea Actions: ci.yml (Pint + PHPUnit), deploy.yml (déploiement SSH) - Suppression de l'ancien workflow GitHub cassé - En-têtes de sécurité: ajout CSP et Permissions-Policy - RGPD: droit à l'effacement (anonymisation du compte) + tests - Correctifs: ForceHttps hors env testing, timestamps du modèle Utilisateur, suppression des migrations en doublon (migrate échouait sur base neuve) - Qualité: formatage Laravel Pint sur l'ensemble du code - Documentation dossier technique (docs/) + .docx + .pptx Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
62 lines
2.4 KiB
Markdown
62 lines
2.4 KiB
Markdown
# 03 — Outil de gestion des versions
|
|
|
|
Projet **(RE)Sources Relationnelles** — Bloc INFCDAAL3
|
|
|
|
## 1. Outil choisi : Git + Gitea (auto-hébergé)
|
|
|
|
Le versionnement du code repose sur **Git**, hébergé sur une instance
|
|
**Gitea** auto-hébergée par l'équipe :
|
|
|
|
- Instance : `https://gitea.sam-coffre.duckdns.org/`
|
|
- Motivations du choix :
|
|
- **Maîtrise des données** : hébergement sur notre propre serveur (cohérent
|
|
avec un contexte ministériel / RGPD, pas de dépendance à un tiers).
|
|
- **Léger et open source** : Gitea est simple à administrer et gratuit.
|
|
- **Fonctionnalités complètes** : dépôts Git, *pull requests*, *issues*,
|
|
*releases*, et **Gitea Actions** (CI/CD) intégrés.
|
|
|
|
## 2. Organisation du dépôt
|
|
|
|
- **Branche principale** : `master` (branche de référence, protégée, déployée).
|
|
- **Branches de fonctionnalité** *(recommandé)* : une branche par fonctionnalité
|
|
(`feature/…`), fusionnée via *pull request* après relecture.
|
|
- Fichiers de configuration Git présents : `.gitignore`, `.gitattributes`,
|
|
`.editorconfig` (cohérence entre développeurs).
|
|
|
|
## 3. Convention de nommage des commits
|
|
|
|
Convention recommandée (type *Conventional Commits*) :
|
|
|
|
```
|
|
<type>: <description courte>
|
|
|
|
Types : feat, fix, docs, style, refactor, test, chore
|
|
Exemples :
|
|
feat: ajout de la création de ressources
|
|
fix: correction de la redirection HTTPS
|
|
docs: rédaction du plan de sécurisation
|
|
```
|
|
|
|
## 4. Flux de travail (workflow) proposé
|
|
|
|
1. Créer une branche depuis `master` : `git checkout -b feature/ma-fonctionnalite`.
|
|
2. Développer + commits atomiques.
|
|
3. Pousser la branche : `git push origin feature/ma-fonctionnalite`.
|
|
4. Ouvrir une **Pull Request** sur Gitea.
|
|
5. La **CI** (Pint + tests) s'exécute automatiquement sur la PR.
|
|
6. Relecture par un pair, puis fusion dans `master`.
|
|
7. La fusion déclenche le **déploiement automatique** en production.
|
|
|
|
## 5. Gestion des livraisons (releases)
|
|
|
|
- Utilisation des **tags Git** pour marquer les versions : `v1.0.0`, `v1.1.0`…
|
|
- Convention **SemVer** : `MAJEUR.MINEUR.CORRECTIF`.
|
|
- Les *Releases* Gitea documentent chaque version livrée (notes de version).
|
|
|
|
## 6. Sécurité du dépôt
|
|
|
|
- Aucun secret versionné : `.env`, clés et certificats sont exclus via
|
|
`.gitignore`.
|
|
- Accès au dépôt restreint aux membres de l'équipe (comptes Gitea).
|
|
- Historique complet et traçable (auteur, date, message de chaque modification).
|