Meta-Upsun
La source de vérité publique d'Upsun : images, runtimes, régions et extensions PHP, servis par une API versionnée.
- Rôle
- Contributeur, au sein de l'équipe Advocacy : nombreuses routes de l'API, dont celles dédiées à l'expérience développeur
- Période
- oct. 2025 – en cours · Upsun
- Stack
- REST API
- OpenAPI
- JSON Schema
- Scalar
- GitHub Actions
- SchemaStore
- Upsun
Contexte
Les données de référence d'Upsun (images disponibles, versions supportées, régions, extensions PHP) étaient éparpillées : dépôt de la documentation, fichiers de registre édités à la main, outils qui les recopiaient ou les réinterprétaient. Au total, 36 dépôts Git et 4 API amont (dont endoflife.date et l'API Upsun) contribuaient à l'information. Les mises à jour étaient manuelles, la source de vérité introuvable et les données incohérentes d'un outil à l'autre.
Le projet et ma contribution
Meta-Upsun est porté par l'équipe Advocacy. J'y ai beaucoup contribué, en ajoutant une bonne partie des routes de l'API, notamment des routes techniques pensées pour l'expérience développeur, que les éditeurs de code consomment directement.
- Un registre unifié des images, runtimes, régions et extensions, validé par un schéma à chaque modification.
- Une API REST versionnée, en lecture seule, sur meta.upsun.com, en JSON ou en YAML, avec des réponses ciblées : le registre complet, un runtime précis, uniquement ses versions, les régions filtrées par fournisseur ou par zone, les extensions d'une version de PHP.
- Une interface web pour tester l'API, avec Scalar : chaque route se teste directement depuis le navigateur, sans outil ni code, et Scalar génère les exemples d'appel (
curl…). J'ai contribué à la rendre plus claire et mieux documentée. - Un schéma de validation dynamique de
.upsun/config.yaml, ma contribution la plus visible : le schéma principal référence, par$ref, deux routes que j'ai ajoutées et qui listent en temps réel les versions supportées des runtimes et des services, tirées du registre. Il est référencé sur SchemaStore : VS Code, JetBrains et les autres éditeurs proposent l'autocomplétion deruntime.typeetservice.typeet signalent une version non supportée avant le déploiement.
Choix d'architecture
- Lecture seule par construction : aucune route d'écriture. Toute modification passe par une pull request relue, ce qui garde l'historique et la traçabilité.
- Un statut de cycle de vie à quatre niveaux (supported, deprecated, retired, decommissioned) aligné sur les projets amont, au lieu de l'ancien couple supporté / déprécié.
- Livré avec les outils d'Upsun : CI/CD, environnements de prévisualisation par branche, validation en staging avant la mise en production.
- Alimenté automatiquement par le Meta Version Updater.
Résultats
- Une source canonique unique, consommée par la documentation (qui migre vers l'API au lieu de tableaux Markdown recopiés), les outils internes, les SDK PHP et Node.js (générés depuis la spécification OpenAPI qu'elle sert), les automatisations des clients et l'écosystème.
- Des mises à jour publiées en quelques jours au lieu de quelques semaines.
- Une meilleure expérience développeur : l'erreur de version est vue dans l'éditeur, pas au déploiement.


