Pular para o conteúdo

Segmentação

Por padrão, um ambiente serve a todo dispositivo o padrão da flag. Segmentação é como você serve outra coisa a alguns dispositivos: beta testers, uma versão específica do app, 10% de todo mundo. Esta página explica a máquina; o guia de rollout mostra como usá-la, passo a passo.

As regras testam tags — pequenos fatos chave/valor sobre o dispositivo que está perguntando. Os SDKs enviam algumas tags embutidas automaticamente (appVersion, appBuild, osVersion, platform, sdkVersion), e o seu app pode adicionar as suas, como cohort: "beta".

Vale saber duas coisas sobre tags desde cedo:

  • Tags são avaliadas e esquecidas. O FortressFlag as usa para responder à única requisição em que chegaram e então as descarta — elas nunca são armazenadas nem registradas em log. Não existe histórico de tags em lugar nenhum, por design.
  • Tags são afirmações do seu app. Uma tag pode carregar qualquer coisa que o seu código coloque nela — então não coloque segredos nem dados pessoais dos seus usuários em valores de tag. Mantenha-as em coortes, versões e configuração.

Regras: uma lista ordenada, a primeira que corresponder vence

Seção intitulada “Regras: uma lista ordenada, a primeira que corresponder vence”

Cada flag + ambiente tem uma lista ordenada de regras. Uma regra é um grupo de condições unidas por E — cohort é beta E appVersion ≥ 2.0 — mais o valor que ela serve ao corresponder.

A avaliação é simples e vale a pena internalizar:

  1. As regras são verificadas de cima para baixo.
  2. A primeira regra cujas condições todas valem decide o valor. Nada abaixo dela é consultado — a ordem é significado, e você pode reordenar regras no painel.
  3. Uma condição sobre uma tag que o dispositivo não enviou não vale. Sem tag, sem correspondência — a regra é pulada, nunca é um erro.
  4. Se nenhuma regra corresponder, o padrão da flag é servido.

Uma regra sem condições sempre corresponde — é a forma “todo o resto” que você coloca no fim de uma lista.

Condições podem comparar versões: appVersion ≥ 2.0. As versões são divididas nos pontos e comparadas numericamente, da esquerda para a direita, e componentes ausentes valem zero — então 2.0 é igual a 2.0.0, e 2.10 é mais nova que 2.9. Uma versão de dispositivo que não se interpreta como números separados por pontos (digamos, 2.0-beta) simplesmente faz a condição não valer. Sufixos de pré-release não são suportados — compare versões simples com pontos.

Segmentos: um pedaço de regra que você nomeia e reutiliza

Seção intitulada “Segmentos: um pedaço de regra que você nomeia e reutiliza”

Um segmento é uma lista de condições unidas por E com nome — beta-testers, internal-devices — que você define uma vez para toda a sua organização e referencia a partir de regras em várias flags e ambientes. Edite o segmento, e toda regra que o usa acompanha.

Esse alcance é exatamente o motivo pelo qual editar um segmento exige permissão de nível de produção: um segmento referenciado por uma regra de produção muda a produção quando muda, seja quem for que o salve.

Qualquer regra pode carregar uma porcentagem de rollout: em vez de corresponder a todo dispositivo que passa pelas suas condições, ela corresponde apenas aos primeiros N% deles. É assim que “10% dos beta testers” funciona — primeiro as condições, depois o filtro de porcentagem.

Três propriedades tornam os rollouts seguros para confiar:

  • Sticky. Se um dispositivo está dentro da porcentagem é calculado a partir da identidade do dispositivo e da chave da flag — o mesmo dispositivo recebe a mesma resposta em toda requisição. Ninguém pisca para dentro e para fora de um rollout, e subir de 10% para 20% mantém os 10% originais dentro.
  • Por flag. O cálculo mistura a chave da flag, então um rollout de 10% em uma flag e um rollout de 10% em outra pegam décimos diferentes da sua frota. Não existem 10% de dispositivos permanentemente azarados que recebem todo experimento de uma vez.
  • Nada é armazenado. A participação na coorte é aritmética pura, recalculada a cada requisição — o FortressFlag não guarda nenhum registro de quais dispositivos estão em qual rollout. Não há nada para vazar e nada para limpar.

Generosos o bastante para você normalmente não encontrá-los, fixos para que os payloads fiquem limitados: até 20 regras por flag por ambiente, 5 condições por regra (uma referência a segmento conta como uma e pode conter até 10 próprias), chaves de tag com até 64 caracteres, valores de condição com até 256.