Quickstart de Python

Em poucos minutos o seu serviço em Python vai avaliar feature flags in-process — sem salto de rede por verificação, sem latência no caminho das suas requisições, um polling atendendo toda requisição que o seu processo trata.

Zero dependências: o SDK é biblioteca padrão pura, no Python 3.11 e posteriores. Funciona igual dentro de um app asyncio — a avaliação é uma leitura simples em memória, então não há nada para aguardar com await.

1. Instale

O SDK mora em um repositório público no GitHub — instale-o direto de lá, fixado na release:

pip install "git+https://github.com/FortressFlag/FortressFlag_SDK_python@v1.0.0"

Se você omitir @v1.0.0, vai acompanhar a branch development em vez disso — útil para testar uma correção, não o que você quer em produção.

2. A chave de servidor — um segredo de verdade

Este SDK usa uma chave de servidor (ffs_…), e ela é o oposto das chaves de cliente que os SDKs de mobile e web carregam: ela consegue baixar o seu ruleset completo, regras de segmentação incluídas. Trate-a exatamente como uma senha de banco de dados — uma variável de ambiente ou um gerenciador de segredos, nunca código, nunca um repositório, nunca um log. As duas classes de chave, lado a lado.

3. Inicie o cliente

import os

import fortressflag

try:
    client = fortressflag.create(
        fortressflag.Configuration(key=os.environ["FF_SERVER_KEY"])
    )
except fortressflag.MalformedKeyError:
    # O único lugar em que o SDK levanta exceção: uma chave malformada, antes de qualquer coisa ser servida.
    raise SystemExit(1)

client.start(timeout=15.0)  # retorna no primeiro ruleset (ou no prazo)

# ... o seu serviço roda; verificações de flag agora são chamadas de função em memória.

start nunca levanta exceção — se a primeira busca não conseguir chegar a tempo, o cliente continua tentando na thread em segundo plano e quem chama recebe os fallbacks enquanto isso. O poller é uma thread daemon: ele nunca impede o seu interpretador de sair.

4. Avalie uma flag

enabled = client.bool_value(
    "new-checkout",
    fortressflag.Context(
        key="user-42",  # a sua chave de contexto estável: um id de usuário, um id de sessão — você escolhe
        tags={"cohort": "beta"},
    ),
    False,  # o fallback se a flag for desconhecida ou nada tiver sido buscado ainda
)

client.string_value e client.number_value funcionam do mesmo jeito. A key de contexto é o que os rollouts percentuais usam para distribuir — passe o mesmo identificador de forma consistente e cada usuário recebe uma coorte estável. É dado seu: o SDK nunca valida, armazena nem registra isso em log.

É isso — o seu serviço está avaliando flags localmente. Uma mudança no painel chega a todo processo em cerca de um minuto.

A avaliação nunca falha

bool_value, string_value e number_value sempre respondem e nunca levantam exceção — um problema com flags nunca pode derrubar o seu serviço. Um processo reiniciado serve os fallbacks do ponto de chamada até a primeira busca chegar (ou defina cache_path na configuração para persistir o último ruleset em um arquivo à sua escolha, e os reinícios retomam dele instantaneamente). Nem uma chave revogada quebra nada: o SDK continua avaliando com o último ruleset que baixou até você entregar uma chave nova.

Para onde ir agora

• Como as flags chegam ao seu app — o server plane, explicado
• Chaves — crie, rotacione e revogue chaves ffs_
• Segmentação — as regras que o seu serviço agora está avaliando