Ciblage

Par défaut, un environnement sert à chaque appareil la valeur par défaut du flag. Le ciblage est la façon de servir autre chose à certains appareils : les bêta-testeurs, une version précise de l’app, 10 % de tout le monde. Cette page explique la machine ; le guide de déploiement progressif vous accompagne dans son utilisation.

Les tags : ce que voient les règles

Les règles testent des tags — de petits faits clé/valeur sur l’appareil qui demande. Les SDK envoient automatiquement quelques tags intégrés (appVersion, appBuild, osVersion, platform, sdkVersion), et votre app peut ajouter les siens, comme cohort: "beta".

Deux choses à savoir tôt sur les tags :

• Les tags sont évalués puis oubliés. FortressFlag les utilise pour répondre à la seule requête avec laquelle ils sont arrivés, puis les jette — ils ne sont jamais stockés et jamais journalisés. Il n’existe d’historique des tags nulle part, par conception.
• Les tags sont les affirmations de votre app. Un tag peut porter tout ce que votre code y met — alors ne mettez pas de secrets ni de données personnelles de vos utilisateurs dans les valeurs de tags. Limitez-les aux cohortes, aux versions et à la configuration.

Les règles : une liste ordonnée, la première correspondance gagne

Chaque couple flag + environnement a une liste ordonnée de règles. Une règle est un groupe de conditions combinées par ET — cohort vaut beta ET appVersion ≥ 2.0 — plus la valeur qu’elle sert en cas de correspondance.

L’évaluation est simple et vaut la peine d’être intériorisée :

1. Les règles sont vérifiées de haut en bas.
2. La première règle dont toutes les conditions sont vérifiées décide de la valeur. Rien en dessous n’est consulté — l’ordre fait sens, et vous pouvez réordonner les règles dans le tableau de bord.
3. Une condition sur un tag que l’appareil n’a pas envoyé n’est pas vérifiée. Pas de tag, pas de correspondance — la règle est sautée, jamais une erreur.
4. Si aucune règle ne correspond, la valeur par défaut du flag est servie.

Une règle sans conditions correspond toujours — c’est la forme « tous les autres » que vous placez en bas d’une liste.

Comparaisons de versions

Les conditions peuvent comparer des versions : appVersion ≥ 2.0. Les versions sont découpées sur les points et comparées numériquement, de gauche à droite, et les composants manquants valent zéro — donc 2.0 égale 2.0.0, et 2.10 est plus récent que 2.9. Une version d’appareil qui ne se lit pas comme des nombres séparés par des points (disons 2.0-beta) rend simplement la condition non vérifiée. Les suffixes de pré-version ne sont pas pris en charge — comparez des versions à points simples.

Les segments : un morceau de règle que vous nommez et réutilisez

Un segment est une liste de conditions en ET nommée — beta-testers, internal-devices — que vous définissez une fois pour toute votre organisation et que vous référencez depuis des règles à travers flags et environnements. Modifiez le segment, et chaque règle qui l’utilise suit.

Cette portée est exactement la raison pour laquelle modifier un segment exige une permission de niveau production : un segment référencé par une règle de production change la production quand il change, quelle que soit la personne qui l’enregistre.

Déploiements progressifs

N’importe quelle règle peut porter un pourcentage de déploiement : au lieu de correspondre à chaque appareil qui passe ses conditions, elle ne correspond qu’aux premiers N % d’entre eux. C’est ainsi que « 10 % des bêta-testeurs » fonctionne — les conditions d’abord, le seuil de pourcentage ensuite.

Trois propriétés rendent les déploiements progressifs fiables :

• Stable. Qu’un appareil soit dans le pourcentage ou non est calculé à partir de l’identité de l’appareil et de la clé du flag — le même appareil obtient la même réponse à chaque requête. Personne n’entre et ne sort d’un déploiement par à-coups, et passer de 10 % à 20 % garde les 10 % d’origine dedans.
• Par flag. Le calcul mélange la clé du flag, donc un déploiement à 10 % sur un flag et un déploiement à 10 % sur un autre attrapent des dixièmes différents de votre parc. Il n’y a pas de 10 % d’appareils éternellement malchanceux qui reçoivent toutes les expériences à la fois.
• Rien n’est stocké. L’appartenance à une cohorte est de l’arithmétique pure, recalculée à chaque requête — FortressFlag ne garde aucune trace de quels appareils sont dans quel déploiement. Il n’y a rien à faire fuir et rien à nettoyer.

Limites

Assez généreuses pour que vous ne les rencontriez pas d’habitude, fixes pour que les charges utiles restent bornées : jusqu’à 20 règles par flag et par environnement, 5 conditions par règle (une référence à un segment compte pour une et peut en contenir jusqu’à 10 en propre), des clés de tag jusqu’à 64 caractères, des valeurs de condition jusqu’à 256.

Où aller ensuite

• Configurez un déploiement progressif — la tâche, étape par étape
• Environnements et projets — le ciblage est par environnement
• Comment les flags arrivent à votre app — pourquoi les appareils ne voient jamais vos règles