Targeting

Per impostazione predefinita, un ambiente serve a ogni dispositivo il valore predefinito del flag. Il targeting è il modo per servire qualcos’altro ad alcuni dispositivi: i beta tester, una versione specifica dell’app, il 10% di tutti. Questa pagina spiega il meccanismo; la guida al rollout ti accompagna nell’usarlo.

Tag: cosa vedono le regole

Le regole testano i tag — piccoli fatti chiave/valore sul dispositivo che sta chiedendo. Gli SDK inviano automaticamente alcuni tag integrati (appVersion, appBuild, osVersion, platform, sdkVersion), e la tua app può aggiungere i propri, come cohort: "beta".

Due cose sui tag vale la pena saperle subito:

• I tag vengono valutati e dimenticati. FortressFlag li usa per rispondere all’unica richiesta con cui sono arrivati, poi li scarta — non vengono mai memorizzati né registrati nei log. Non esiste da nessuna parte uno storico dei tag, per scelta.
• I tag sono affermazioni della tua app. Un tag può trasportare qualsiasi cosa il tuo codice ci metta — quindi non mettere segreti o dati personali dei tuoi utenti nei valori dei tag. Limitali a coorti, versioni e configurazione.

Regole: una lista ordinata, vince la prima corrispondenza

Ogni coppia flag + ambiente ha una lista ordinata di regole. Una regola è un gruppo di condizioni in AND tra loro — cohort è beta AND appVersion ≥ 2.0 — più il valore che serve in caso di corrispondenza.

La valutazione è semplice e vale la pena interiorizzarla:

1. Le regole vengono controllate dall’alto verso il basso.
2. La prima regola le cui condizioni valgono tutte decide il valore. Nulla sotto di essa viene consultato — l’ordine è significato, e puoi riordinare le regole nella dashboard.
3. Una condizione su un tag che il dispositivo non ha inviato non vale. Niente tag, niente corrispondenza — la regola viene saltata, mai un errore.
4. Se nessuna regola corrisponde, viene servito il valore predefinito del flag.

Una regola senza condizioni corrisponde sempre — è la forma «tutti gli altri» che metti in fondo a una lista.

Confronti tra versioni

Le condizioni possono confrontare versioni: appVersion ≥ 2.0. Le versioni vengono divise sui punti e confrontate numericamente, da sinistra a destra, e i componenti mancanti valgono zero — quindi 2.0 equivale a 2.0.0, e 2.10 è più recente di 2.9. Una versione del dispositivo che non si interpreta come numeri separati da punti (per esempio 2.0-beta) fa semplicemente non valere la condizione. I suffissi pre-release non sono supportati — confronta versioni puntate semplici.

Segmenti: un pezzo di regola a cui dai un nome e che riusi

Un segmento è una lista AND di condizioni con un nome — beta-testers, internal-devices — che definisci una volta per tutta la tua organizzazione e a cui fai riferimento dalle regole di flag e ambienti diversi. Modifica il segmento, e ogni regola che lo usa lo segue.

Proprio questa portata è il motivo per cui modificare un segmento richiede un permesso di livello produzione: un segmento a cui fa riferimento una regola di produzione cambia la produzione quando cambia, chiunque lo salvi.

Rollout percentuali

Qualsiasi regola può portare una percentuale di rollout: invece di corrispondere a ogni dispositivo che supera le sue condizioni, corrisponde solo al primo N% di essi. È così che funziona «il 10% dei beta tester» — prima le condizioni, poi il filtro percentuale.

Tre proprietà rendono i rollout affidabili:

• Sticky. Se un dispositivo è dentro la percentuale viene calcolato a partire dalla sua identità e dalla chiave del flag — lo stesso dispositivo ottiene la stessa risposta a ogni richiesta. Nessuno entra ed esce a intermittenza da un rollout, e alzare dal 10% al 20% mantiene dentro il 10% originale.
• Per flag. Il calcolo mescola la chiave del flag, quindi un rollout al 10% su un flag e un rollout al 10% su un altro catturano decimi diversi della tua flotta. Non esiste un 10% di dispositivi permanentemente sfortunato che riceve tutti gli esperimenti insieme.
• Niente viene memorizzato. L’appartenenza a una coorte è pura aritmetica, ricalcolata a ogni richiesta — FortressFlag non tiene traccia di quali dispositivi siano in quale rollout. Non c’è niente da far trapelare e niente da ripulire.

Limiti

Abbastanza generosi da non incontrarli di solito, fissi perché i payload restino limitati: fino a 20 regole per flag per ambiente, 5 condizioni per regola (un riferimento a un segmento conta come una e può contenerne fino a 10 proprie), chiavi dei tag fino a 64 caratteri, valori delle condizioni fino a 256.

Prossimi passi

• Configura un rollout percentuale — il compito, passo dopo passo
• Ambienti e progetti — il targeting è per ambiente
• Come i flag raggiungono la tua app — perché i dispositivi non vedono mai le tue regole