docs: ajouter documentation complète du projet dans docs/

This commit is contained in:
syoul
2025-12-02 17:00:00 +01:00
parent e342d06fff
commit 92348cd8d9
6 changed files with 938 additions and 0 deletions

39
docs/README.md Normal file
View File

@@ -0,0 +1,39 @@
# Documentation AJR Technology Radar
Bienvenue dans la documentation du projet AJR Technology Radar (CoeurBox).
## Vue d'ensemble
Le Technology Radar AJR est une application web interactive qui présente les technologies, outils, méthodes et plateformes utilisées et évaluées par AJR. Il est basé sur le framework [aoe_technology_radar](https://github.com/AOEpeople/aoe_technology_radar).
Le radar est organisé en quatre quadrants et quatre anneaux (rings) pour classifier chaque technologie selon son niveau d'adoption et sa catégorie.
## Structure de la documentation
Cette documentation est organisée en plusieurs sections :
- **[Architecture](./architecture.md)** - Structure du projet, organisation des fichiers et composants
- **[Configuration](./configuration.md)** - Configuration du radar, quadrants, anneaux et personnalisation
- **[Développement](./developpement.md)** - Guide pour développer et tester localement
- **[Déploiement](./deploiement.md)** - Instructions pour déployer le radar en production
- **[Contribution](./contribution.md)** - Guide pour ajouter de nouvelles technologies au radar
## Liens utiles
- **Radar en ligne** : https://www.coeurbox.syoul.fr
- **Dépôt Git** : https://git.open.us.org/AJR/TechradarDev
- **Framework source** : https://github.com/AOEpeople/aoe_technology_radar
## Démarrage rapide
Pour démarrer rapidement le projet en local :
```bash
npm install
npm run serve
```
Puis ouvrir http://localhost:3000/techradar dans votre navigateur.
Pour plus de détails, consultez le [guide de développement](./developpement.md).

98
docs/architecture.md Normal file
View File

@@ -0,0 +1,98 @@
# Architecture du projet
## Vue d'ensemble
Le projet AJR Technology Radar est une application web statique construite avec le framework `aoe_technology_radar`. L'application génère un site web interactif à partir de fichiers Markdown organisés par dates de release.
## Structure des répertoires
```
TechradarDev/
├── radar/ # Contenu du radar organisé par dates
│ ├── 2017-03-01/ # Release de mars 2017
│ ├── 2018-03-01/ # Release de mars 2018
│ ├── 2019-11-01/ # Release de novembre 2019
│ ├── 2021-07-01/ # Release de juillet 2021
│ ├── 2022-03-28/ # Release de mars 2022
│ ├── 2023-02-23/ # Release de février 2023
│ ├── 2023-11-01/ # Release de novembre 2023
│ ├── 2024-07-10/ # Release de juillet 2024
│ └── 2025-04-10/ # Release d'avril 2025 (actuelle)
├── public/ # Fichiers statiques publics
│ ├── images/ # Images utilisées dans les descriptions
│ ├── logo.svg # Logo AJR
│ ├── favicon.ico # Icône du site
│ └── robots.txt # Configuration pour les robots
├── docker/ # Configuration Docker pour le déploiement
│ ├── Dockerfile # Image Docker de production
│ ├── docker-compose.yml # Configuration Docker Compose
│ ├── docker-compose.labels.yml # Labels pour le déploiement
│ └── docker-compose.local.yml # Configuration locale
├── docs/ # Documentation du projet
├── config.json # Configuration principale du radar
├── custom.css # Styles personnalisés
├── about.md # Page "À propos" du radar
├── package.json # Dépendances Node.js
├── Dockerfile # Dockerfile alternatif (racine)
├── docker-compose.yml # Docker Compose alternatif (racine)
├── docker-entrypoint.sh # Script d'entrée Docker
└── .drone.yml # Configuration CI/CD Drone
```
## Format des fichiers radar
Chaque technologie (blip) est définie dans un fichier Markdown avec un en-tête YAML front matter :
```markdown
---
title: "Nom de la technologie"
ring: adopt|trial|assess|hold
quadrant: languages-and-frameworks|methods-and-patterns|platforms-and-aoe-services|tools
tags: [tag1, tag2]
---
Description de la technologie en Markdown.
```
### Métadonnées
- **title** : Nom de la technologie
- **ring** : Anneau du radar (adopt, trial, assess, hold)
- **quadrant** : Quadrant du radar
- **tags** : Tags pour le filtrage (optionnel)
## Flux de traitement
1. **Lecture des fichiers** : Le framework lit tous les fichiers `.md` dans les dossiers `radar/`
2. **Parsing** : Extraction des métadonnées YAML et du contenu Markdown
3. **Génération** : Création d'une application React statique
4. **Build** : Compilation en fichiers HTML/CSS/JS statiques
5. **Serve** : Service via un serveur web statique
## Dépendances principales
- **aoe_technology_radar** : Framework principal (dépendance GitHub)
- **Node.js** : Runtime JavaScript (version 20+)
- **npm** : Gestionnaire de paquets
## Configuration
La configuration principale se trouve dans `config.json` et définit :
- Les quadrants et leurs descriptions
- Les anneaux (rings) et leurs significations
- Les couleurs et le style
- Les options d'affichage
- Les métadonnées du site
Voir [configuration.md](./configuration.md) pour plus de détails.
## Build et déploiement
Le projet utilise deux commandes principales :
- `npm run build` : Génère les fichiers statiques
- `npm run serve` : Lance un serveur de développement
Le déploiement se fait via Docker avec plusieurs configurations selon l'environnement.
Voir [deploiement.md](./deploiement.md) pour plus de détails.

173
docs/configuration.md Normal file
View File

@@ -0,0 +1,173 @@
# Configuration
## Fichier config.json
Le fichier `config.json` contient toute la configuration du radar. Il définit l'apparence, le comportement et la structure du radar.
## Structure de configuration
### Paramètres de base
```json
{
"basePath": "/",
"baseUrl": "",
"editUrl": "https://git.open.us.org/syoul/TechradarDev/_edit/main/radar/{release}/{id}.md",
"logoFile": "logo.svg"
}
```
- **basePath** : Chemin de base pour l'application (modifié dynamiquement en Docker)
- **baseUrl** : URL de base du site
- **editUrl** : Template d'URL pour éditer les fichiers (utilise {release} et {id})
- **logoFile** : Nom du fichier logo dans `public/`
### Options d'affichage (toggles)
```json
{
"toggles": {
"showChart": true,
"showTagFilter": true,
"showQuadrantList": true,
"showEmptyRings": false
}
}
```
- **showChart** : Affiche le graphique radar interactif
- **showTagFilter** : Active le filtre par tags
- **showQuadrantList** : Affiche la liste des quadrants
- **showEmptyRings** : Affiche les anneaux vides
### Sections
```json
{
"sections": ["radar", "tags", "list"]
}
```
Définit l'ordre des sections dans l'interface.
### Couleurs
```json
{
"colors": {
"foreground": "#fff",
"background": "#173d7a",
"highlight": "#029df7",
"content": "#fff",
"text": "#575757",
"link": "#029df7",
"border": "rgba(255, 255, 255, 0.1)",
"tag": "rgba(255, 255, 255, 0.1)"
}
}
```
Personnalisation des couleurs de l'interface.
### Quadrants
Les quadrants définissent les quatre catégories principales :
1. **Languages & Frameworks** : Langages et frameworks de développement
2. **Methods & Patterns** : Méthodes et patterns de développement
3. **Platforms & Operations** : Plateformes et opérations
4. **Tools** : Outils de développement
Chaque quadrant a :
- **id** : Identifiant unique
- **title** : Titre affiché
- **description** : Description du quadrant
- **color** : Couleur associée
### Anneaux (Rings)
Les anneaux classifient les technologies selon leur niveau d'adoption :
1. **Adopt** : Recommandé, utilisé avec succès
2. **Trial** : À essayer, prometteur
3. **Assess** : À évaluer, à surveiller
4. **Hold** : À éviter, à remplacer
Chaque anneau a :
- **id** : Identifiant unique
- **title** : Titre affiché
- **description** : Description de l'anneau
- **color** : Couleur associée
- **radius** : Rayon dans le graphique (0-1)
- **strokeWidth** : Épaisseur du trait
### Flags (Drapeaux)
Les flags marquent les changements entre versions :
- **new** : Nouveau dans cette version
- **changed** : Modifié récemment
- **default** : Inchangé
### Graphique
```json
{
"chart": {
"size": 800,
"blipSize": 12
}
}
```
- **size** : Taille du graphique en pixels
- **blipSize** : Taille des points (blips) sur le graphique
### Labels (Textes)
Les labels permettent de personnaliser tous les textes de l'interface, notamment :
- Titre du site
- Textes des pages
- Messages d'erreur
- Placeholders
- Footer
## Personnalisation
### Modifier les couleurs
Éditez la section `colors` dans `config.json` avec les codes hexadécimaux souhaités.
### Ajouter un quadrant
Ajoutez un nouvel objet dans le tableau `quadrants` avec les propriétés requises.
### Modifier les descriptions
Les descriptions des quadrants et anneaux peuvent être modifiées directement dans `config.json`.
### Styles personnalisés
Le fichier `custom.css` permet d'ajouter des styles CSS personnalisés qui seront appliqués à l'application.
## Variables d'environnement
En Docker, la variable `BASE_PATH` peut être utilisée pour modifier dynamiquement le `basePath` dans `config.json`. Le script `docker-entrypoint.sh` effectue cette modification au démarrage.
## Tags disponibles
Les tags suivants sont établis pour classifier les technologies :
- architecture
- security
- devops
- frontend
- agile
- coding
- quality assurance
- ci/cd
- ux/ui
- documentation
Les tags sont utilisés dans les fichiers Markdown des blips et permettent le filtrage dans l'interface.

200
docs/contribution.md Normal file
View File

@@ -0,0 +1,200 @@
# Guide de contribution
## Vue d'ensemble
Ce guide explique comment contribuer au Technology Radar AJR en ajoutant, modifiant ou supprimant des technologies (blips).
## Processus de contribution
### 1. Préparer l'environnement
Voir le [guide de développement](./developpement.md) pour l'installation et la configuration de l'environnement local.
### 2. Créer une branche
```bash
git checkout -b feature/nom-de-la-technologie
```
### 3. Ajouter ou modifier un blip
#### Ajouter un nouveau blip
1. Créer un fichier Markdown dans le dossier de release approprié :
```
radar/2025-04-10/nom-technologie.md
```
2. Utiliser le format standard :
```markdown
---
title: "Nom de la technologie"
ring: adopt|trial|assess|hold
quadrant: languages-and-frameworks|methods-and-patterns|platforms-and-aoe-services|tools
tags: [tag1, tag2]
---
Description de la technologie.
## Avantages
- Point 1
- Point 2
## Cas d'usage AJR
Description de l'utilisation chez AJR.
```
#### Modifier un blip existant
1. Localiser le fichier dans le dossier de release
2. Modifier le contenu ou les métadonnées
3. Si vous changez le ring ou le quadrant, documenter la raison
#### Supprimer un blip
Si une technologie doit être retirée du radar :
- La déplacer vers le ring "hold" plutôt que de la supprimer
- Ou la supprimer complètement si elle n'est plus pertinente
### 4. Tester localement
```bash
npm run serve
```
Vérifier :
- L'affichage correct du blip
- Le positionnement dans le bon quadrant et ring
- La lisibilité du contenu
- Le fonctionnement des tags
### 5. Commiter les changements
```bash
git add radar/2025-04-10/nom-technologie.md
git commit -m "feat: ajouter [technologie] au quadrant [quadrant]"
```
### 6. Pousser et créer une pull request
```bash
git push origin feature/nom-de-la-technologie
```
Créer une pull request sur le dépôt Git.
## Guidelines de contenu
### Choix du ring
- **Adopt** : Technologie utilisée avec succès dans plusieurs projets, stable et recommandée
- **Trial** : Technologie testée avec succès, à considérer pour de nouveaux projets
- **Assess** : Technologie prometteuse, à évaluer selon les besoins
- **Hold** : Technologie à éviter ou à remplacer, mais peut être maintenue dans les projets existants
### Choix du quadrant
- **Languages & Frameworks** : Langages de programmation et frameworks de développement
- **Methods & Patterns** : Méthodologies, patterns architecturaux, pratiques de développement
- **Platforms & Operations** : Plateformes cloud, infrastructure, services opérationnels
- **Tools** : Outils de développement, utilitaires, logiciels
### Tags
Utiliser les tags établis :
- architecture
- security
- devops
- frontend
- agile
- coding
- quality assurance
- ci/cd
- ux/ui
- documentation
Ajouter plusieurs tags si la technologie couvre plusieurs domaines.
### Qualité du contenu
- **Clarté** : Description claire et concise
- **Pertinence** : Focus sur l'utilisation chez AJR
- **Objectivité** : Présenter les avantages et inconvénients
- **Concision** : Rester factuel et éviter les détails superflus
## Format des commits
Utiliser des messages de commit clairs :
```
feat: ajouter [technologie] au quadrant [quadrant]
fix: corriger la description de [technologie]
update: déplacer [technologie] de trial à adopt
docs: améliorer la documentation de [technologie]
```
## Créer une nouvelle release
Quand créer une nouvelle release :
1. **Périodicité** : Généralement tous les 3-6 mois
2. **Changements significatifs** : Plusieurs nouveaux blips ou changements majeurs
3. **Événements** : Après des évaluations importantes
### Processus de release
1. Créer un nouveau dossier avec la date :
```bash
mkdir radar/2025-07-15
```
2. Copier les blips pertinents depuis la release précédente
3. Ajouter les nouveaux blips
4. Mettre à jour les blips existants si nécessaire
5. Documenter les changements majeurs
## Review process
Les contributions sont revues pour :
- **Exactitude** : Les informations sont correctes
- **Pertinence** : La technologie est pertinente pour AJR
- **Format** : Le format Markdown est correct
- **Classification** : Le ring et quadrant sont appropriés
- **Qualité** : Le contenu est clair et utile
## Questions fréquentes
### Puis-je ajouter une technologie que je n'ai pas encore utilisée ?
Non. Le radar ne contient que des technologies testées au moins une fois par l'équipe.
### Comment décider entre deux quadrants ?
Choisir le quadrant le plus approprié. Si c'est ambigu, discuter avec l'équipe.
### Puis-je modifier un blip d'une release précédente ?
Généralement non. Les releases précédentes sont figées. Créer un nouveau blip dans la release actuelle si nécessaire.
### Comment gérer les technologies obsolètes ?
Les déplacer vers le ring "hold" avec une explication de pourquoi elles ne sont plus recommandées.
## Ressources
- [Guide de développement](./developpement.md)
- [Configuration](./configuration.md)
- [Architecture](./architecture.md)
- Framework source : https://github.com/AOEpeople/aoe_technology_radar
## Contact
Pour toute question sur les contributions, contacter l'équipe AJR ou ouvrir une issue sur le dépôt Git.

239
docs/deploiement.md Normal file
View File

@@ -0,0 +1,239 @@
# Guide de déploiement
## Vue d'ensemble
Le projet peut être déployé de plusieurs façons :
- Docker Compose (recommandé pour la production)
- Docker simple
- Build statique avec serveur web
## Déploiement avec Docker
### Configuration Docker
Le projet contient plusieurs configurations Docker :
- `docker/Dockerfile` : Dockerfile principal avec multi-stage build
- `docker/docker-compose.yml` : Configuration de base
- `docker/docker-compose.labels.yml` : Labels pour le reverse proxy
- `docker/docker-compose.local.yml` : Configuration pour développement local
- `Dockerfile` (racine) : Dockerfile alternatif
- `docker-compose.yml` (racine) : Docker Compose alternatif
### Build de l'image Docker
#### Avec le Dockerfile principal
```bash
cd docker
docker compose build
```
#### Avec build args
```bash
docker build \
--build-arg BASE_PATH="/techradar" \
--build-arg UID=1000 \
--build-arg GID=1000 \
-f docker/Dockerfile \
-t techradar:latest \
.
```
### Variables d'environnement
- **BASE_PATH** : Chemin de base pour l'application (défaut: `/`)
- **UID** : User ID pour l'utilisateur dans le conteneur (défaut: 1000)
- **GID** : Group ID pour l'utilisateur dans le conteneur (défaut: 1000)
### Démarrage avec Docker Compose
```bash
cd docker
docker compose up -d
```
L'application sera accessible sur le port 3000.
### Configuration du basePath
Le script `docker-entrypoint.sh` modifie dynamiquement le `basePath` dans `config.json` au démarrage du conteneur en utilisant la variable d'environnement `BASE_PATH`.
## Déploiement statique
### Build des fichiers statiques
```bash
npm install
npm run build
```
Les fichiers sont générés dans le répertoire `build/`.
### Servir avec un serveur web
#### Nginx
```nginx
server {
listen 80;
server_name coeurbox.syoul.fr;
root /chemin/vers/build;
index index.html;
location / {
try_files $uri $uri/ /index.html;
}
}
```
#### Apache
```apache
<VirtualHost *:80>
ServerName coeurbox.syoul.fr
DocumentRoot /chemin/vers/build
<Directory /chemin/vers/build>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
```
## Déploiement avec Drone CI
Le projet est configuré pour le déploiement automatique via Drone CI (`.drone.yml`).
### Pipeline de déploiement
1. **Build** : Construction de l'image Docker
2. **Déploiement** : Lancement du conteneur avec Docker Compose
3. **Notification** : Envoi d'une notification Telegram
### Configuration Drone
Le pipeline utilise :
- Variables d'environnement dynamiques basées sur le dépôt Git
- Labels pour le reverse proxy (Traefik)
- Notifications Telegram en cas de succès/échec
### Variables d'environnement Drone
- `DRONE_REPO_OWNER` : Propriétaire du dépôt
- `DRONE_REPO_NAME` : Nom du dépôt
- `DRONE_COMMIT_BRANCH` : Branche du commit
Ces variables sont utilisées pour générer le `BASE_PATH` dynamiquement.
## Déploiement en production
### Étapes recommandées
1. **Préparer l'environnement**
```bash
git clone https://git.open.us.org/AJR/TechradarDev.git
cd TechradarDev
```
2. **Configurer les variables**
- Définir `BASE_PATH` selon votre configuration
- Ajuster les ports si nécessaire
3. **Build et démarrage**
```bash
cd docker
docker compose -f docker-compose.yml -f docker-compose.labels.yml up -d --build
```
4. **Vérifier le déploiement**
- Accéder à l'URL configurée
- Vérifier les logs : `docker compose logs -f`
### Reverse proxy
Le projet est configuré pour fonctionner derrière un reverse proxy (Traefik) via les labels dans `docker-compose.labels.yml`.
### Sécurité
- Utiliser HTTPS en production
- Configurer les headers de sécurité appropriés
- Limiter l'accès si nécessaire
- Surveiller les logs
## Mise à jour
### Mettre à jour le contenu
1. Modifier les fichiers dans `radar/`
2. Rebuild l'image :
```bash
docker compose build
docker compose up -d
```
### Mettre à jour les dépendances
1. Modifier `package.json` si nécessaire
2. Rebuild l'image complète
## Monitoring
### Logs Docker
```bash
# Voir les logs
docker compose logs -f
# Logs du dernier démarrage
docker compose logs --tail=100
```
### Santé de l'application
L'application expose le port 3000. Vérifier la santé avec :
```bash
curl http://localhost:3000/techradar
```
## Rollback
En cas de problème, revenir à une version précédente :
```bash
# Arrêter le conteneur actuel
docker compose down
# Checkout une version précédente
git checkout <commit-hash>
# Rebuild et redémarrer
docker compose build
docker compose up -d
```
## Troubleshooting
### Problème de basePath
Si l'application ne se charge pas correctement :
- Vérifier la variable `BASE_PATH`
- Vérifier les logs du conteneur
- Vérifier la configuration du reverse proxy
### Problème de permissions
Si des erreurs de permissions apparaissent :
- Vérifier les UID/GID dans le Dockerfile
- Vérifier les permissions des volumes montés
### Problème de build
Si le build échoue :
- Vérifier la version de Node.js
- Vérifier les dépendances npm
- Nettoyer le cache : `docker system prune -a`

189
docs/developpement.md Normal file
View File

@@ -0,0 +1,189 @@
# Guide de développement
## Prérequis
- **Node.js** : Version 20 ou supérieure
- **npm** : Gestionnaire de paquets Node.js
- **Git** : Pour cloner et gérer le dépôt
## Installation
### Cloner le dépôt
```bash
git clone https://git.open.us.org/AJR/TechradarDev.git
cd TechradarDev
```
### Installer les dépendances
```bash
npm install
```
Cette commande installe le framework `aoe_technology_radar` depuis GitHub.
## Développement local
### Démarrer le serveur de développement
```bash
npm run serve
```
Le serveur démarre sur http://localhost:3000/techradar
### Build de production
Pour générer les fichiers statiques :
```bash
npm run build
```
Les fichiers générés sont créés dans le répertoire `build/` (généré par le framework).
## Structure des fichiers radar
### Créer un nouveau blip
1. Créer un nouveau fichier Markdown dans le dossier de release approprié :
```
radar/2025-04-10/nom-technologie.md
```
2. Utiliser le format suivant :
```markdown
---
title: "Nom de la technologie"
ring: adopt|trial|assess|hold
quadrant: languages-and-frameworks|methods-and-patterns|platforms-and-aoe-services|tools
tags: [tag1, tag2]
---
Description de la technologie en Markdown.
## Avantages
- Point 1
- Point 2
## Cas d'usage
Description des cas d'usage chez AJR.
```
### Format des métadonnées
- **title** (obligatoire) : Nom de la technologie
- **ring** (obligatoire) : `adopt`, `trial`, `assess`, ou `hold`
- **quadrant** (obligatoire) : Un des quatre quadrants définis dans `config.json`
- **tags** (optionnel) : Tableau de tags pour le filtrage
### Exemple complet
```markdown
---
title: "Docker"
ring: trial
quadrant: tools
tags: [devops, ci/cd]
---
Docker est une plateforme de conteneurisation qui permet de packager des applications avec leurs dépendances.
## Avantages
- Isolation des environnements
- Portabilité entre environnements
- Facilite le déploiement
## Utilisation chez AJR
Nous utilisons Docker pour containeriser nos applications et faciliter le déploiement.
```
## Modifier un blip existant
1. Localiser le fichier dans le dossier de release approprié
2. Modifier le contenu Markdown
3. Si nécessaire, modifier les métadonnées (ring, quadrant, tags)
4. Tester localement avec `npm run serve`
## Créer une nouvelle release
1. Créer un nouveau dossier avec la date au format `YYYY-MM-DD` :
```bash
mkdir radar/2025-07-15
```
2. Copier les blips pertinents depuis la release précédente ou créer de nouveaux blips
3. Mettre à jour les blips existants si nécessaire
## Ajouter des images
1. Placer les images dans `public/images/`
2. Référencer dans les fichiers Markdown :
```markdown
![Description](images/nom-image.png)
```
## Personnalisation CSS
Le fichier `custom.css` permet d'ajouter des styles personnalisés. Les styles sont appliqués globalement à l'application.
## Débogage
### Vérifier les erreurs de format
Le framework valide les fichiers Markdown. En cas d'erreur :
- Vérifier la syntaxe YAML front matter
- Vérifier que les valeurs de `ring` et `quadrant` correspondent aux valeurs définies dans `config.json`
- Vérifier la syntaxe Markdown
### Problèmes courants
1. **Erreur de parsing YAML** : Vérifier les guillemets et l'indentation
2. **Blip non affiché** : Vérifier que le quadrant et le ring sont corrects
3. **Images non chargées** : Vérifier le chemin relatif depuis `public/`
## Workflow recommandé
1. Créer une branche Git pour vos modifications
2. Ajouter/modifier les fichiers radar
3. Tester localement avec `npm run serve`
4. Vérifier l'affichage et le formatage
5. Commiter et pousser les changements
6. Créer une pull request si applicable
## Commandes utiles
```bash
# Installer les dépendances
npm install
# Démarrer le serveur de développement
npm run serve
# Build de production
npm run build
# Vérifier les fichiers modifiés
git status
# Voir les différences
git diff
```
## Intégration continue
Le projet utilise Drone CI pour l'intégration continue. Voir `.drone.yml` pour la configuration.
Les builds automatiques :
- Construisent l'image Docker
- Déploient sur l'environnement de test
- Envoient des notifications Telegram