Modifier le monorepo d'une plateforme de travaux distribués et le tester avec de vrais services

## Lancer les commandes depuis la racine et choisir la vérification selon le type de paquet Exécutez les commandes de l'espace de travail depuis la racine du dépôt au moyen de l'enveloppe du gestionnaire de paquets dont la version est figée. Compilez les dépendances requises avant de démarrer une application ou un outil en ligne de commande, et utilisez les filtres de l'espace de travail pour limiter les travaux au graphe des paquets concernés. Suivez exactement la politique d'installation des dépendances du dépôt. Si elle exige de modifier les déclarations de paquets avant l'installation, faites-le au lieu d'exécuter une commande d'ajout qui contourne les choix de versions pouvant être examinés. Choisissez la vérification selon le rôle du paquet : - Les applications et les paquets privés utilisent une vérification statique des types lorsque leur compilation ne prouve pas leur exactitude. - Les paquets publiés utilisent leur véritable processus de compilation afin d'exercer les exportations et les artefacts générés. - Les modifications majeures, les nouveaux fichiers, les travaux sur les schémas et les remaniements étendus font l'objet d'une vérification locale des types ou de la compilation. - Les modifications minuscules peuvent reposer sur des contrôles ciblés et l'intégration continue lorsque le projet l'autorise explicitement. N'exécutez pas une compilation étendue simplement parce qu'elle vous est familière. Utilisez le contrôle capable d'échouer réellement pour la couche modifiée. ## Tester files d'attente et bases de données avec de vrais conteneurs de services, sans mocks Placez les tests avec le code source et utilisez l'unique exécuteur de tests pris en charge par le dépôt. Commencez par le paquet concerné ou un seul fichier de test, et ne compilez d'abord ses dépendances que si l'espace de travail l'exige. Ne remplacez pas les bases de données, les files d'attente ou les caches par des objets simulés lorsque le projet fournit des conteneurs de service jetables. Utilisez des auxiliaires de test isolés qui fournissent de véritables options de connexion et un état propre pour : - Le comportement des files d'attente et des caches. - Les transactions relationnelles et les migrations. - Les processus combinés qui franchissent les limites entre stockages. Réservez une limite de test unitaire légère aux fonctions pures. Pour le comportement de l'infrastructure, préférez un service réel contrôlé afin que la sérialisation, la temporisation, les nouvelles tentatives et la sémantique des transactions restent observables. Exécutez le formatage et les corrections automatiques du lint avant le dernier contrôle de lint en lecture seule. Préférez les importations statiques ; n'utilisez le chargement dynamique que pour un cycle inévitable, un avantage mesuré du découpage du code ou une véritable condition d'exécution. ## Consigner les changements des paquets publiés et garder une seule version pour les dépendances partagées Ajoutez une fiche de changement versionnée chaque fois qu'un paquet publié ou une intégration change. Choisissez par défaut une version corrective pour les corrections et les petites modifications compatibles, confirmez une version mineure avec les responsables et ne sélectionnez jamais une version majeure sans approbation explicite. Pour un comportement exclusivement côté serveur sans modification d'un paquet publié, utilisez le mécanisme de note de changement du serveur plutôt qu'une fiche de version de paquet. Rédigez les descriptions de publication pour les utilisateurs : - Commencez par le comportement qui a changé. - Utilisez si possible une seule phrase simple. - Omettez les noms internes d'outils, de files d'attente, de stockages et de déploiements. - Ne présentez pas la mise en œuvre comme l'avantage obtenu. Maintenez les dépendances volontairement partagées sur une même version exacte dans tout l'espace de travail lorsque l'identité des types à l'exécution en dépend. Avant d'ajouter une telle dépendance, trouvez la version déjà figée et reproduisez-la exactement ; des plages ou des versions parallèles peuvent rendre les schémas d'un paquet incompatibles avec les consommateurs d'un autre. ## Suivre le chemin d'une requête avant de déplacer du travail entre couches Comprenez le parcours de la requête avant de le modifier : 1. Une requête externe entre dans l'API et l'application du tableau de bord. 2. Les services valident l'intention et appellent le moteur de cycle de vie des exécutions. 3. Le moteur conserve l'état et place le travail dans une file d'attente. 4. Un superviseur prend le travail en charge et gère son exécution isolée. 5. Les résultats reviennent par le moteur de cycle de vie. 6. L'état transactionnel et les événements analytiques circulent vers leurs stockages distincts. Conservez les SDK publics, les outils en ligne de commande, les types partagés, les extensions de compilation, les points d'ancrage clients, les processus des files d'attente, les bases de données, l'analytique, la planification et les moteurs d'exécution dans leurs paquets déclarés. Importez les types publics partagés par les sous-chemins pris en charge plutôt que par les racines générales des paquets lorsque le contrat d'exportation l'exige. Ne déplacez pas les responsabilités entre ces couches par commodité. Toute modification de la planification, de la mise en file d'attente, de l'exécution ou de la persistance doit tenir compte de l'ensemble de la transition d'état et du parcours d'échec. ## Ne pas rétablir le moteur d'exécution retiré et refuser proprement les anciens clients par une erreur Lorsqu'un ancien moteur a été retiré, les noms de répertoires historiques ou les énumérations de compatibilité ne prouvent pas qu'il fonctionne encore. Considérez la documentation de l'architecture actuelle et le graphe actif des paquets comme faisant autorité. Ne réintroduisez jamais le parcours retiré pour satisfaire une ancienne branche ou une ancienne requête. Le traitement de compatibilité peut reconnaître une version obsolète uniquement pour la rejeter ou la finaliser proprement avec une erreur côté client ; il ne doit pas acheminer du travail vers un code d'exécution inexistant ni transformer un rejet attendu en erreur de serveur. Avant de modifier le comportement de compatibilité : - Retracez la sélection du moteur actif. - Vérifiez comment les clients obsolètes sont identifiés. - Préservez une sémantique d'erreur propre. - Ajoutez des tests pour le parcours actuel et le rejet de la version retirée. Conservez les conseils SDK versionnés et les règles d'agent générées dans leur phase de maintenance dédiée. Ne mettez pas à jour les ensembles d'instructions distribués, sauf si la tâche les inclut explicitement. ## Écrire les tâches avec le SDK public actuel et mettre à jour la documentation quand il change Définissez les tâches durables par le point d'entrée actuel du SDK public. N'importez pas d'anciens sous-chemins de version et ne rétablissez pas une API obsolète de définition des travaux. Une définition de tâche doit comporter : - Un identifiant stable. - Un contrat d'entrée typé. - Une fonction d'exécution asynchrone. - Des erreurs explicites pour les entrées non valides. - Un comportement idempotent ou une limite de nouvelle tentative documentée pour les effets de bord. Traitez le code intégré aux images d'exécution des clients comme du code d'exécution public, même s'il provient du paquet de l'outil en ligne de commande. Vérifiez ensemble les exportations du paquet, les dépendances intégrées et le comportement du conteneur. Mettez à jour la documentation publique et les exemples lorsque le contrat du SDK change. Conservez la documentation du produit sur le site qui lui est réservé et respectez les règles locales de formatage et de navigation de ce site. ## Exécuter une vraie tâche de bout en bout sur une build locale Utilisez un projet de référence maintenu pour tester les modifications du SDK et de la plateforme sur une compilation locale. Reliez le projet de référence aux paquets de l'espace de travail au lieu de tester par erreur un paquet déjà publié. Exécutez le parcours dans l'ordre : 1. Démarrez les services requis de stockage et de file d'attente. 2. Appliquez les migrations de la base de données et initialisez l'organisation et le projet de référence. 3. Compilez le SDK, l'outil en ligne de commande et les paquets concernés. 4. Démarrez l'application API en arrière-plan et vérifiez son point de contrôle d'état. 5. Démarrez l'agent d'exécution local des tâches depuis le projet de référence relié. 6. Attendez un signal explicite indiquant que l'agent d'exécution est prêt. 7. Déclenchez une tâche représentative par l'interface de contrôle prise en charge. 8. Interrogez ou répertoriez les exécutions jusqu'à ce que l'état terminal attendu apparaisse. 9. Examinez le résultat renvoyé et l'état d'exécution conservé. Ne déclarez pas la réussite de bout en bout à partir de la seule compilation. Conservez la sortie des commandes ou les identifiants d'exécution comme preuves, et arrêtez les processus d'arrière-plan lorsque la vérification est terminée. ## Épingler les images de conteneur multiplateformes et retirer les marqueurs de débogage avant la fusion Figez les images de conteneur sur des condensats d'index multiplateformes, et non sur des condensats d'image propres à une architecture. Sélectionnez le condensat depuis la page de publication indépendante de la plateforme afin que le développement et l'intégration continue résolvent l'architecture appropriée. Utilisez des repères de débogage structurés pendant le développement des parcours distribués : - Ajoutez des marqueurs aux transitions d'état, aux limites des files d'attente et aux appels externes. - N'utilisez que des espaces de noms d'application enregistrés ; n'en inventez pas de nouveau sans approbation. - Effacez les traces existantes avant de reproduire un bogue. - Interrogez avec des limites et une pagination par curseur. - Conservez les marqueurs temporaires sur la branche de développement tant que l'enquête est en cours. - Retirez les marqueurs et les importations avant la fusion. Les réviseurs ne doivent pas signaler une instrumentation temporaire reconnue simplement parce qu'elle existe sur la branche. Ils doivent vérifier qu'elle ne peut pas atteindre la production et que l'étape de retrait fait partie de l'achèvement. ## Lancer seulement les vérifications adaptées au changement et indiquer ce qui a été omis Avant le transfert, examinez l'ensemble complet des fichiers modifiés et n'exécutez que les contrôles applicables : - Formatage, correction du lint et contrôle de lint en lecture seule. - Vérification des types pour les applications et les paquets privés. - Compilations réelles pour les paquets publiés. - Tests ciblés avec des conteneurs de service jetables. - Une fiche de changement de paquet ou une note de serveur à la bonne limite. - Des versions partagées figées exactement. - Des tests du moteur actuel et de la version retirée lorsque le routage a changé. - Un condensat d'image multiplateforme lorsque les références d'image ont changé. - Une exécution avec un projet de référence relié lorsque le SDK ou le comportement d'exécution a changé. - Le retrait de l'instrumentation temporaire de débogage avant la fusion. Indiquez ce qui a été exécuté, ce qui a réussi et tout contrôle volontairement omis avec sa raison. Ne prétendez pas à l'exactitude de l'exécution, du paquet ou du conteneur à partir d'un contrôle plus faible qui ne peut pas l'observer.