Automation Plateforme¶

Objet¶

Ce document fixe la répartition cible entre la documentation centrale heymoov-docs, le repository d'automation heymoov-platform et les repositories applicatifs.

Sources De Vérité¶

heymoov-docs : documentation publiée, architecture, runbooks, décisions et index.
heymoov-platform : automation exécutable, scripts, Makefile, inventory et templates.
repositories applicatifs : code, workflows applicatifs et documentation locale proche du code.

Le sens principal des liens est heymoov-docs vers les repositories spécialisés. Les repositories spécialisés peuvent garder un lien d'orientation vers heymoov-docs, mais ne doivent pas dupliquer les runbooks publiés.

Repository `heymoov-platform`¶

heymoov-platform porte l'état exécutable de la plateforme.

Il doit contenir deux blocs distincts :

provisioning bas niveau, à ajouter ;
bootstrap d'environnement, déjà amorcé.

Provisioning Bas Niveau¶

Ce bloc préparera les hosts et le socle système :

VMs, volumes, réseau, firewall/security groups et IPs ;
DNS de base si cette responsabilité est automatisée ;
accès SSH, users de base et sudo ;
paquets OS : PostgreSQL, Redis, Nginx, Certbot, Python et outils système ;
répertoires et groupes socle : /etc/heymoov, /opt/heymoov-platform, heymoov-deploy ;
installation versionnée des binaires plateforme : Hydra, Mercure/Caddy, goose ;
durcissement minimal, logs et maintenance OS.

Ce bloc ne déploie aucune release applicative.

Bootstrap D'environnement¶

Ce bloc part d'un host conforme et prépare un environnement logique :

inventory dev, staging, prod ;
templates nginx, systemd et env runtime ;
bootstrap PostgreSQL, Redis, Hydra, Mercure et Swagger Basic Auth ;
création des webroots statiques ;
création et vérification des environnements GitHub ;
installation et vérification des runners self-hosted.

Références techniques locales :

Références opérateur publiées :

Repositories Applicatifs¶

Les repositories applicatifs gardent les éléments qui doivent évoluer avec le code :

heymoov-api : migrations, Swagger généré, scripts de release API et contrats backend proches du code.
heymoov-web : runtime config frontend, workflow Web CI, build Vite et docs auth web locales.
heymoov-landing : workflow Hugo, contenu landing, build Dart Sass et documentation de contenu.
heymoov-mobile : build mobile, passkeys mobile et notes propres aux plateformes iOS/Android.

Environnements Standards¶

Les environnements standards sont représentés par l'inventory plateforme, pas par des branches longues dans heymoov-platform.

Environnement	Host	Slot	Landing	Webapp
`dev`	`ls2i-staging`	`primary`	`dev.heymoov.com`	`app.dev.heymoov.com`
`staging`	`ls2i-staging`	`secondary`	`staging.heymoov.com`	`app.staging.heymoov.com`
`prod`	`ls2i-rdscrap`	`primary`	`heymoov.com`	`app.heymoov.com`

La topologie effective se vérifie depuis heymoov-platform :

make topology-env ENV=staging CHECK=1

Orchestration Staging¶

Le provisioning bas niveau reste séparé. Sur un host déjà conforme, les targets d'orchestration staging composent les briques de bootstrap existantes :

make bootstrap-runtime-stack-heymoov-staging DRY_RUN=1
make bootstrap-edge-heymoov-staging DRY_RUN=1
make bootstrap-static-frontends-heymoov-staging DRY_RUN=1
make bootstrap-heymoov-staging DRY_RUN=1
make verify-heymoov-staging-readiness

bootstrap-heymoov-staging prépare le runtime logique, l'edge nginx/certificats et les cibles statiques webapp/landing. Il ne provisionne pas les paquets OS, les users socle, les firewalls, les binaires plateforme ou les hosts eux-mêmes.

Convention Mercure¶

Deux conventions coexistent volontairement :

backend runtime MERCURE_TOPICS_PREFIX : avec slash final, par exemple https://app.staging.heymoov.com/ ;
web runtime RUNTIME_MERCURE_TOPIC_PREFIX : sans slash final, par exemple https://app.staging.heymoov.com.

Le backend concatène directement le suffixe de topic. Le frontend ajoute lui-même le séparateur de chemin.