Créer un émulateur cloud local qui fonctionne avec les SDK et CLI officiels

## Reproduire les formats de requête et de réponse du vrai cloud plutôt que prendre des raccourcis Donnez la priorité : 1. à la compatibilité avec le protocole cloud de la plateforme source ; 2. au comportement attendu par les clients SDK et CLI officiels ; 3. à la réutilisation des modèles existants de l’émulateur ; 4. à l’exactitude plutôt qu’à la facilité ; 5. aux modifications limitées et testables. N’ajoutez pas de structures de point de terminaison personnalisées et ne simplifiez pas les formats de requête et de réponse pour faciliter l’implémentation. N’effectuez pas de refactorisation étendue, sauf si le comportement demandé l’exige. Avant toute modification, déterminez le service, son rôle sur le plan de contrôle ou le plan de données, la famille de protocoles, l’implémentation existante à prendre pour modèle, les incidences sur la configuration, le stockage et la documentation, ainsi que le plus petit plan de test utile. Lorsque le comportement n’est pas clair, privilégiez d’abord le contrat de la plateforme source, puis le comportement établi de l’émulateur et enfin les attentes de la suite de compatibilité. Si la tâche exige une modification architecturale entre plusieurs services, exposez les compromis au lieu de refactoriser aveuglément. ## Garder les gestionnaires de protocole légers et la logique métier dans les services Adoptez une conception de service en couches : - les contrôleurs ou gestionnaires analysent l’entrée du protocole et produisent des réponses compatibles avec celui-ci ; - les services contiennent la logique métier et lèvent l’exception partagée du domaine cloud ; - les modèles représentent les données du domaine ; - les registres, la configuration, les fabriques de stockage, les services de cycle de vie, les analyseurs, les générateurs et les mappeurs d’exceptions fournissent l’infrastructure partagée. Gardez les contrôleurs légers. Réutilisez les utilitaires partagés et reproduisez la structure du service établi le plus proche avant d’introduire un nouveau modèle. Acheminez les défaillances du domaine au moyen du type d’exception partagé. Les flux de requête et XML doivent utiliser le mappeur d’exceptions standard ; les flux de protocole JSON doivent renvoyer le corps d’erreur structuré requis. Les types de retour des contrôleurs doivent rester compatibles avec les contraintes de réflexion de compilation anticipée et de sérialisation. Utilisez l’injection par constructeur, des accolades pour les conditions et du code explicite. Ne laissez jamais un bloc `catch` vide ; si une exception est volontairement tolérée, journalisez assez de contexte pour permettre son diagnostic. ## Identifier le vrai protocole de chaque service avant d’ajouter une opération Déterminez le véritable protocole d’échange avant d’ajouter une opération : - les protocoles de requête utilisent des actions encodées sous forme de formulaire et des réponses XML ; - les protocoles de type JSON RPC utilisent un en-tête de cible et du JSON structuré ; - REST JSON et REST XML utilisent des chemins de ressources avec leur format de corps natif ; - les services du plan de données peuvent nécessiter des proxys TCP natifs plutôt que des API de gestion HTTP. Utilisez le générateur et l’analyseur XML partagés, ainsi que les constantes d’espace de noms. N’analysez jamais du XML avec des expressions régulières. Alignez les erreurs JSON sur la structure d’erreur du protocole cible. Certains services exposent plusieurs chemins de compatibilité. Maintenez les gestionnaires alternatifs alignés et testez-les ensemble. Traitez les points de terminaison de découverte d’identité selon leur véritable protocole ouvert, au lieu de les contraindre à suivre le modèle de l’API de gestion. Validez les API de gestion au moyen de clients SDK officiels, et pas seulement avec des requêtes HTTP construites manuellement. L’acceptation d’une charge utile manuelle ne prouve pas la compatibilité de la sérialisation du client, des en-têtes, des erreurs, de la pagination ou de la génération d’URL. ## Toujours mettre à jour ensemble les modes de stockage et les fichiers de configuration Prenez en charge le stockage au moyen de la fabrique partagée et des modes déclarés ; n’instanciez jamais directement une implémentation de stockage dans un service. Respectez les hooks de cycle de vie pour le chargement, le vidage, les points de contrôle ou le comportement d’écriture anticipée. Lorsque les valeurs par défaut de l’interface diffèrent des valeurs déployées, considérez le fichier de configuration d’exécution du dépôt comme la source de référence effective. Pour les comportements liés au stockage : 1. mettez à jour l’interface de configuration canonique ; 2. mettez à jour la configuration d’exécution principale ; 3. mettez à jour la configuration de test ; 4. raccordez le mode par l’intermédiaire de la fabrique de stockage ; 5. vérifiez l’intégration au cycle de vie. Pour toute configuration destinée aux utilisateurs, mettez également à jour la documentation et respectez la convention établie de nommage des variables d’environnement. Examinez l’URL de base, le nom d’hôte, les valeurs par défaut de région et de compte, les plages de ports, les racines de persistance et le réseau des conteneurs lorsqu’ils influencent les identifiants ou les points de terminaison générés. Ajoutez les nouveaux champs de manière compatible et maintenez synchronisés la configuration partagée, le stockage et l’enregistrement des services. ## Tester la compatibilité avec les SDK officiels, pas avec des requêtes manuelles Utilisez des tests unitaires pour le comportement isolé du service et des tests d’intégration pour le traitement du protocole, la persistance et l’état visible par le client. L’exécution ordonnée des tests d’intégration n’est acceptable que lorsque le comportement est volontairement avec état. Toute modification de l’analyse, de la forme des réponses, des erreurs, de la sémantique de persistance, de la génération d’URL, de l’activation des services ou des chemins de protocole alternatifs exige une couverture automatisée. Pendant l’itération, exécutez d’abord un test ciblé, puis la suite directement concernée. Utilisez le projet de compatibilité lorsqu’une modification peut affecter le comportement réel des SDK. Préférez les assertions fondées sur les SDK aux requêtes HTTP brutes et documentez tout écart volontaire par rapport à la plateforme source. Lorsque des chemins de protocole alternatifs exposent la même opération, vérifiez que leur sémantique est équivalente. Lorsque l’état persiste, vérifiez le comportement de chargement et de vidage dans les modes de stockage concernés. Ne concluez pas à la compatibilité à partir de seules requêtes manuelles. Si le comportement a changé sans couverture automatisée, indiquez le test manquant et la raison pour laquelle il n’a pas pu être ajouté. ## Terminer entièrement chaque nouveau service sans modifier au passage les processus de publication Lorsque vous ajoutez un service, créez son contrôleur, son service et ses modèles ; enregistrez-le ; ajoutez la configuration canonique et la configuration de test ; raccordez le stockage par l’intermédiaire de la fabrique ; ajoutez des tests ; et mettez la documentation à jour. Avant de terminer : - exécutez les tests pertinents et les vérifications de compatibilité des protocoles ; - confirmez qu’aucun point de terminaison personnalisé ni format d’échange motivé par la facilité n’a été introduit ; - vérifiez les mises à jour de la configuration, du stockage, du cycle de vie et de la documentation ; - contrôlez la cohérence des URL et des identifiants de ressources générés ; - maintenez une journalisation structurée et discrète dans les chemins critiques. Gardez les demandes d’intégration ciblées, préservez le comportement existant sauf si la modification est explicite et séparez les refactorisations sans rapport. Utilisez des types de commit conventionnels et une attribution exclusivement humaine. Considérez les branches de version, les étiquettes et les processus de publication comme une infrastructure critique. Une fusion dans la branche de développement ne prouve pas à elle seule la stabilité d’une version. Ne modifiez pas incidemment le comportement de mise en version lors de l’implémentation des fonctionnalités du service.