Une version est un maillage, pas un numéro de version
Un lecteur peut ouvrir un ancien client alors qu'un service a déjà changé. Un catalogue de contenu peut être mis à jour avant le client qui comprend un nouvel élément. Un déploiement de configuration peut atteindre une région avant l'autre. Un serveur peut accepter des formes de requête anciennes et nouvelles pendant un certain temps, puis retirer un adaptateur. Traiter tout cela comme une version 42.
Commencer par nommer les dimensions de la version séparément. Au minimum, enregistrer la compilation du client, la révision du backend ou du service, la version du protocole, le schéma ou l'enregistrement de la version, la version du catalogue de contenu, la version de configuration et l'état de migration. Certains produits ont aussi besoin de la version de groupe d'actifs, de la fonction-flag, de la capacité du système d'exploitation, de la cohorte de comptes ou de la région.
La question utile n’est pas « le client le plus récent a-t-il réussi le test ? », mais « quelles combinaisons peuvent coexister, que doit faire chaque combinaison et lesquelles sont interdites ? ». Une politique de compatibilité transforme cette question en un ensemble de tests délimité. Elle précise les plages de versions acceptées, les mécanismes de traduction, les dispositifs de désactivation d’urgence, les refus contrôlés et les critères de déploiement avant qu’un incident en production n’oblige l’équipe à improviser.
Écrire les contraintes de compatibilité dans les deux sens
La compatibilité est souvent asymétrique. Un nouveau client peut accepter les demandes d'un ancien client, alors qu'un ancien client ne peut pas comprendre un nouveau client. Un nouveau client peut lire une ancienne sauvegarde après la migration, tandis qu'un ancien client ne doit pas rouvrir la version migrée. Un nouveau contenu peut être inoffensif pour les anciens clients lorsqu'il est caché par un drapeau de fonctionnalité, mais dangereux lorsqu'un ancien client traite un type d'élément inconnu comme un défaut valide.
Par exemple : le client 5 peut authentifier contre le service 7 par le protocole 2; le client 4 peut lire le catalogue 10 uniquement lorsque les éléments du type X sont exclus; sauvegarde du schéma 3 peut migrer vers 5 par les bords supportés; configuration 12 ne doit pas activer une fonctionnalité pour les clients ci-dessous construire 6. Inclure une disposition pour les combinaisons non supportées : bloc avant la mutation, servir une représentation compatible, route vers une mise à jour requise, ou tenir le changement jusqu'à ce que l'ancienne cohorte draine.
Un nombre plus élevé ne prouve pas l'existence d'une capacité, et un nombre plus ancien ne prouve pas l'absence d'une fonction. Utilisez la négociation de capacité ou des métadonnées de compatibilité explicites lorsque c'est pratique. Les métadonnées elles-mêmes nécessitent des tests; un drapeau manquant ne devrait pas signifier accidentellement qu'il faut aller de l'avant.
Générer une matrice axée sur les risques
Le produit cartésien complet peut être énorme. Quatre constructions client, trois services, quatre versions de contenu, et cinq états de configuration créent déjà des combinaisons 240 avant que la plate-forme et l'état de migration ne soient considérés.
Ajouter des combinaisons qui traversent un champ de protocole modifié, le bord de migration, la règle d'interprétation du contenu, le chemin de versement ou le drapeau de fonctionnalité. Inclure au moins un chemin en forme de rrollback : un client ou un service revenant à un état compatible précédent après que le nouvel état ait observé des données. Lorsqu'un changement est vraiment isolé, notez pourquoi il n'a pas élargi la matrice au lieu de supposer silencieusement qu'il ne le fait pas.
Certaines défaillances nécessitent trois ou quatre dimensions pour s'aligner : un ancien client, un nouveau catalogue, une sauvegarde migrée, et un drapeau de configuration pourrait être sûr dans chaque paire mais non valide ensemble. Ajoutez des tests de scénario nommés pour ces risques spécifiques au produit. La matrice devrait être revisitée par les personnes qui comprennent les fonctionnalités, pas seulement par un générateur de test.
Tester les anciens et les nouveaux clients vivant ensemble
La coexistence est une condition de déploiement normale. Simulez un ancien client créant ou modifiant l'état pendant qu'un nouveau client le lit, puis inversez l'ordre. Testez les reconnects, les sessions simultanées, les téléchargements interrompus de mise à jour et un utilisateur qui reprend sur un autre périphérique. Pour chaque chemin, identifiez quel côté possède une interprétation autorisée. Un client ne devrait pas inventer une nouvelle valeur de champ que le service traite plus tard comme fiable juste parce que les deux ont été mis à jour dans un essai local.
Les modifications de protocole méritent des adaptateurs explicites. Lorsqu'un champ est rebaptisé, type élargi ou scindé en plusieurs valeurs, tester l'ancienne représentation, la nouvelle représentation et toute couche de traduction. Une traduction doit préserver le sens documenté ou rejeter la requête avant une mutation dangereuse.
La compatibilité client inclut l'expérience utilisateur. Si une vieille construction ne peut pas continuer en toute sécurité, le chemin de mise à jour doit apparaître avant une action mateful, et non après une transaction ratée. Si une fonctionnalité est cachée dans de vieilles constructions, confirmez qu'elle reste cachée dans des menus, des liens profonds, des points d'entrée de type push et des sessions restaurées.
Traiter le contenu et la configuration comme des dépendances exécutables
Les catalogues de contenu et la configuration à distance sont souvent considérés comme des données opérationnelles plutôt que comme des codes. Dans un système en direct, ils sont des dépendances exécutables parce qu'ils modifient ce que signifient les identifiants, quelles caractéristiques apparaissent et quelles règles s'appliquent. Testez un nouveau catalogue de contenu avec des clients anciens et nouveaux. Testez un cache de configuration en panne avec un nouveau service. Testez un drapeau de fonctionnalité permettant un chemin de code avant la présence du contenu requis. Testez un retournement de contenu après que certains joueurs aient acquis des références au nouvel enregistrement.
Utiliser des contrats de contenu en version. Une entrée de catalogue doit déclarer les champs et les capacités nécessaires pour le rendre ou l'exécuter. Un paquet de configuration doit identifier les gammes de clients ou de services qu'il attend. Si un enregistrement dépend d'une capacité indisponible, choisissez un comportement sûr : masquez-le, remplacez un repli documenté, reportez l'activation ou arrêtez le déploiement.
Un changement de schéma peut ajouter un champ par défaut. Un changement de schéma peut retirer un élément, diviser une quête ou modifier une règle d'économie. Ce dernier a besoin d'invariants de domaine et de décisions de récupération, pas seulement d'un test desérializer. Enregistrez quelle version du catalogue et de la configuration a interprété l'état sauvegardé, en particulier lorsqu'une nouvelle lecture ou une recherche de support doit reproduire un résultat.
Prouvez un retour en arrière avant que la version en ait besoin
Demande si un ancien client peut lire l'état écrit par le nouveau client, si un ancien service peut interpréter de nouvelles requêtes, si les enregistrements de contenu nécessitent un nouveau rendeur, et si une migration a franchi une frontière à sens unique. Certains changements sont uniquement vers l'avant. Cela peut être acceptable lorsque déclaré, mais il change le plan de publication : utilisez une cohorte par étapes, une fenêtre de compatibilité, une politique de sauvegarde ou d'instantané et un chemin de support au lieu d'envisager un retour instantané.
Commencer sur l'ancien ensemble compatible, avancer un composant, faire un changement d'état représentatif, puis déplacer un composant sélectionné en arrière. Assister l'état attendu: compatibilité continue, sécurité en lecture seule, refus contrôlé, ou la récupération prévue. Le résultat devrait nommer ce qui a été exécuté et ce qui a été simulé. Un examen ne devrait jamais erreur un diagramme de conception pour une répétition de retour exécutable.
L'enregistrement de la version peut indiquer : les plages de compatibilité supportées, les scénarios exécutés, les risques connus non exécutés, les changements qui sont uniquement vers l'avant, les barrières de déploiement et les conditions d'arrêt. Il ne devrait pas revendiquer la sécurité universelle parce qu'une matrice est passée.
Rendre la preuve dans CI
Exécutez une petite fumée de compatibilité sur chaque changement qui touche les contrats partagés. Exécutez des shards élargis lorsque le client, le protocole, l'enregistrement, le contenu, la configuration ou le code de déploiement changent. Shard par famille de scénarios plutôt que par combinaisons aléatoires : authentification et restauration de session, achat et droits, migration et état sauvegardé, rendu de contenu, comportement lié aux fonctionnalités et retour.
Le rapport de l'IC devrait préserver le tuple sous test et la classification des résultats. Inclure la construction du client, la révision du service, les versions du protocole, du contenu et de la configuration, l'ID du montage ou du scénario, le type d'environnement et la première règle de compatibilité défaillante. Éviter le dumping du compte ou de l'état du joueur.
Examiner ces rapports avec les propriétaires de libération avant d'élargir le déploiement; la preuve de compatibilité est une entrée de décision, et non un tableau de bord décoratif.
Utilisez la minimisation des défaillances lorsqu'un cas de matrice se brise. Le premier tuple défaillant peut contenir des versions ou des drapeaux inutiles. Tenez toujours l'environnement déterministe, réduisez les dimensions tout en préservant la défaillance de compatibilité, et stockez le scénario minimal résultant comme un cas de régression.
Liste de contrôle pratique
- Nommez les dimensions client, service, protocole, schéma, contenu, configuration et migration séparément.
- Écrire les relations de compatibilité supportées, traduites et interdites avec le comportement attendu.
- Inclure les scénarios les plus anciens, les plus récents, les scénarios de transition et les scénarios de renversement.
- Ajouter des tests multidimensionnels nommés où la couverture par paires est insuffisante.
- Tester les anciens et les nouveaux clients créant, lisant et reprenant l'état à travers la même limite de service.
- Traiter les changements de catalogue et de configuration comme des dépendances de compatibilité exécutables.
- Déclarer les migrations vers l'avant seulement et fournir un plan de déploiement ou de rétablissement échelonné.
- Consigner si les preuves sont simulées, exécutables localement, poncées ou vérifiées externement.
- Préserver le tuple d'échec minimal comme scénario de régression examiné.
Foire aux questions
Les essais par paires sont-ils suffisants pour assurer la compatibilité de la libération?
La couverture par paires est un moyen utile de réduire une grande matrice, mais elle ne peut pas prouver toutes les contraintes multidimensionnelles. Utilisez-la pour une large couverture d'interaction, puis ajoutez des scénarios explicites pour des combinaisons à haut risque comme l'état migré plus un nouveau contenu plus un ancien client, ou un retour après qu'une porte de configuration a changé.
Quand un vieux client doit-il être bloqué ?
Bloquez-le avant la mutation lorsqu'elle ne peut pas interpréter en toute sécurité le contenu requis, satisfaire un contrat de protocole ou lire la limite de l'état actuel. Une exigence de mise à jour claire est plus sûre que de continuer avec un défaut qui change le sens. La politique exacte est spécifique au produit, mais la condition et le comportement orienté vers l'utilisateur doivent être testés ensemble.
Un drapeau de fonctionnalité peut-il résoudre la compatibilité par lui-même ?
Non. Un drapeau peut contrôler l'exposition, mais il ne peut pas rendre un protocole, un schéma ou un enregistrement de contenu incompatible. Testez les états mis en cache et mis à jour du drapeau, sa dépendance aux capacités du client, et ce qui se passe si elle change pendant qu'une session est active.
Qu'est-ce que cela implique pour Persistium ?
Persistium est une famille de produits de fiabilité première locale en développement. Cet article décrit une approche test-design, et non une affirmation qu'un produit libéré génère automatiquement toutes les matrices ou fournit la gestion des versions hébergées. Sa direction de continuité explore des preuves limitées pour les types de décisions de compatibilité décrites ici.
