Rattraper le SDK avant qu'il ne puisse dériver

La parité construite au début d'un projet coûte mille fois moins cher que la parité rétro-adaptée après sa sortie. Les liaisons de RakuAI sont co-développées avec le runtime, contrôlées à chaque PR - pour que votre choix de liaison ne vous prive jamais d'une fonctionnalité plus tard.

Déjà nerveux à propos d’un mode de défaillance spécifique que j’ai vu tuer des projets multi-dépôts auparavant, et c’était l’état de départ du samedi matin. Le runtime ajoute une fonctionnalité un week-end et le SDK ne rattrape pas son retard avant le mois prochain. Les exemples dans une liaison fonctionnent et les exemples dans l’autre liaison régressent silencieusement. Les numéros de version cessent de correspondre. La CI sur chaque dépôt est verte et l’intégration entre eux est cassée.

Ce film se termine par un re-platform deux ans plus tard. Je ne construis pas Raku de cette façon. Le plan pour ce week-end était de rattraper le SDK sur le runtime avant que l’écart ne puisse se former, et de laisser derrière assez d’infrastructure pour que l’écart ne puisse plus jamais se former.

Ce qui a atterri du côté SDK

Le SDK a eu un gros week-end. Le côté runtime était plus calme (sa grande poussée a surtout eu lieu le week-end précédent avec la PR #104 qui a fait atterrir VIO/SLAM, l’ordonnanceur de QoS, le harnais de performance, et le pipeline de télémétrie). Celui-ci était le week-end de rattrapage pour les liaisons.

Points forts :

• Parité Unity + Unreal du SDK v0.2.0, avec validation complète
• Exemples HelloAR dans les deux liaisons, avec des démonstrations explicites de basculement
• Interactions d’exemple Unity améliorées avec support multi-objets et tutoriels interactifs
• Documentation API Unreal améliorée avec des exemples d’usage complets
• Flux de travail Agent-Queue Seeder porté vers le dépôt SDK
• Pipeline CI/CD pour la publication du package SDK v0.2 avec versionnage sémantique et automatisation de release
• Documentation et démarrage rapide du SDK v0.2 avec page d’accueil du dépôt et intégration wiki
• Epic #42 : infrastructure de test de parité SDK & Runtime terminée

Le travail de l’Epic #42 est le point marquant. C’est une suite de tests qui exerce les deux liaisons contre les mêmes scénarios canoniques et confirme qu’elles se comportent de la même façon. Unity HelloAR et Unreal HelloAR chargent chacun un modèle, l’ancrent à un marqueur, le rendent, et rapportent la télémétrie. Le test de parité confirme que la télémétrie rapportée par les deux liaisons est dans la tolérance, et que le même modèle se charge correctement dans les deux. Si un changement du runtime casse jamais une liaison sans casser l’autre, le test de parité l’attrape.

Pourquoi le test de parité compte à ce stade

Le SDK Raku n’est pas encore livré. Il n’y a pas de sortie publique. Nous sommes à des mois de ce que quiconque en dehors de l’équipe écrive du code contre cela. Alors pourquoi se soucier de la parité maintenant ?

Parce que le test de parité construit au début d’un projet coûte mille fois moins cher que le test de parité rétro-adapté sur un projet déjà livré. Chaque nouvelle API C que le runtime ajoute est exercée à travers les deux liaisons dès le premier jour. Chaque PR qui touche la surface publique doit soit montrer que le test de parité passe toujours, soit expliquer pourquoi ce n’est pas le cas. Le coût est de quelques minutes par PR. L’économie est des mois de triage en aval quand un partenaire rapporte un problème qui ne se reproduit que sur Unreal et que l’équipe doit comprendre pourquoi.

L’autre raison est que le test de parité fait surface les problèmes architecturaux. Quand une fonctionnalité est facile à exposer dans Unity et difficile dans Unreal, le problème n’est généralement pas dans les liaisons. Il est dans l’API C du runtime. L’asymétrie est un signal. Ce week-end, les tests de parité ont fait surface deux asymétries de ce genre, et la correction dans les deux cas a été de changer la surface API du runtime plutôt que de contourner l’asymétrie dans l’une des liaisons.

Comment fonctionne le flux de travail à deux flux

Le schéma sur lequel je me suis arrêté pour le développement multi-dépôts avec des agents :

Une file d’agent par dépôt. Le runtime a sa propre file d’issues, le SDK a sa propre file d’issues, la documentation a la sienne. Chaque agent travaille à l’intérieur de son dépôt. Aucun agent unique n’essaie de couvrir la couture entre deux dépôts dans une seule PR.

Coordination inter-dépôts au niveau de l’issue. Quand une fonctionnalité nécessite des changements dans les deux dépôts, deux issues couplées sont déposées en même temps, avec des références croisées. La PR du runtime atterrit en premier. La PR du SDK est retenue jusqu’à ce que la PR du runtime soit fusionnée. Ensuite la PR du SDK est mise à jour contre le nouveau build du runtime, re-testée, et fusionnée en quelques heures.

Un ensemble d’exemples canoniques dans chaque liaison. Unity HelloAR et Unreal HelloAR sont les véhicules de test canoniques. Chaque changement d’API C doit être exercé dans les deux. Les exemples ne sont pas des réflexions après coup. Ils font partie de la surface publique.

Les tests de parité comme barrière CI. L’infrastructure de test de parité qui a atterri ce week-end sous forme d’Epic #42 est maintenant exécutée sur chaque PR qui touche l’un ou l’autre dépôt. Si un changement du runtime n’exerce pas les deux liaisons, la PR est bloquée de fusionner jusqu’à ce que le test de parité démontre que le changement fonctionne des deux côtés.

Ce que cela permet pour les bâtisseurs

Si vous êtes un développeur Unity qui pense construire sur Raku éventuellement, la liaison est co-développée avec le runtime, pas poursuivie après lui. L’API Unity ne traînera pas en retard. Les exemples fonctionneront aujourd’hui et fonctionneront en version 1.0.

Si vous êtes un développeur Unreal, la même chose est vraie. La liaison Unreal a une priorité identique à celle de Unity. Les tests de parité le prouvent.

Si vous décidez avec quelle liaison commencer, la réponse est celle qui correspond aux compétences existantes de votre équipe. Le test de parité est ce qui me permet de promettre que le choix de liaison ne vous privera pas de fonctionnalités plus tard.

Si vous êtes un partenaire qui réfléchit à comment ce moteur s’intègre dans votre stack, la surface va être API C plus liaison Unity plus liaison Unreal plus éventuellement quelques autres (Godot est sur la feuille de route, le web natif est sur la feuille de route). Chaque nouvelle liaison doit faire atterrir ses propres tests de parité contre l’ensemble canonique avant de sortir. La discipline est intégrée d’origine.

Honnête sur ce qui est encore brut

Les tests de parité couvrent les bases. L’ancrage basé sur des marqueurs fonctionne dans les deux liaisons. HelloAR se charge et se rend dans les deux. La télémétrie rapporte correctement dans les deux. Les questions de parité plus difficiles, le suivi complet des mains, le pipeline vocal, la synchro de pose multijoueur, ne sont pas encore testées en parité parce que le côté runtime n’est pas terminé. Elles viendront sous la même barrière quand ce sera le cas.

Le pipeline CI pour la publication du SDK v0.2 est en place, mais le package réellement publié n’est pas encore assez stable pour recommander de s’y intégrer. Considérez le SDK comme en développement jusqu’en octobre. En novembre, les tests de parité seront assez profonds pour que la recommandation soit différente.

Ce que je veux retenir de ce week-end

Deux choses.

La parité multi-dépôts est une discipline, pas une fonctionnalité. Le week-end où le SDK a rattrapé le runtime est un week-end sans nouvelle fonctionnalité brillante dans le runtime. Rien de démontrable ne s’est produit. Ce qui s’est produit, c’est que le SDK ne traîne plus en retard. C’est le genre de travail qui, négligé, tue un projet multi-dépôts. Je veux le consigner pour ne pas oublier quand la prochaine grande fonctionnalité du runtime atterrira.

La file d’agents s’échelonne par dépôt. Faire tourner une seule file à travers les deux dépôts dans le même flux de travail a produit une première version de la bouillie de conflits de fusion que j’ai décrite le week-end dernier au niveau du runtime. Séparer les files par dépôt en a éliminé presque toute. Les agents cessent de se marcher dessus quand leurs espaces de problème sont correctement découpés.

Samedi soir, le SDK et le runtime sont en parité. Gros week-end. Le bon genre de week-end.