0001 — GitHub plutôt que GitLab
Contexte
- Usage quotidien de GitLab self-hosté dans le cadre professionnel, avec une forte orientation DevOps et de nombreuses intégrations CI/CD avancées.
- Pour ce hub personnel, l'objectif est une forge simple à administrer, centrée sur la documentation et des scripts légers.
- Contraintes majeures : aucune infrastructure à héberger soi-même, maintenance minimale, intégration directe avec la chaîne de documentation existante.
Décision
- GitHub devient la forge principale pour ce dépôt hub.
- GitHub Pages héberge la documentation générée par Rspress.
- GitLab n'est pas utilisé dans le cadre de ce projet.
Raisons
- Mise en service très rapide et interface immédiate sans configuration complexe.
- Intégration plus riche avec l'écosystème VS Code, les assistants IA et les outils tiers utilisés au quotidien.
- GitHub Pages fournit un hébergement statique natif parfaitement adapté aux docs.
- Moins de friction à l'usage qu'un GitLab cloud pensé pour des équipes DevOps complètes.
- Alignement naturel avec un projet orienté documentation plutôt qu'une plateforme CI/CD exhaustive.
Conséquences
Positives
- Démarrage quasi instantané avec les dépôts et la documentation.
- Maintenance réduite au strict minimum (pas de patch, pas de monitoring).
- Workflow linéaire : push → build docs → publication GitHub Pages.
Négatives
- Fonctionnalités DevOps avancées (review apps, runners personnalisés) moins accessibles.
- Dépendance accrue envers l'écosystème GitHub.
- Divergence avec les outils quotidiens de l'environnement professionnel basé sur GitLab.
Alternatives considérées
- GitLab cloud : écarté car la configuration et la gestion des projets restent plus lourdes que nécessaire pour ce hub.
- Auto-hébergement (GitLab, Gitea, Forgejo) : hors périmètre, car cela impose une infrastructure et une maintenance que l'on veut éviter.
- Autres forges légères (Gitea / Forgejo managés) : rejetées afin de ne pas multiplier les services ni dépendre d'offres hébergées moins intégrées.
Statut
Accepté.