Pular para o conteúdo
FortressFlag Docs

Ambientes e projetos

Dois eixos organizam tudo no FortressFlag: projetos separam suas flags por base de código ou produto, e ambientes separam o valor de cada flag por estágio de deploy. O build dev do seu app lê new-checkout do ambiente dev; o seu app publicado lê da produção. Mesma flag, valores independentes.

Os ambientes são seus para definir

Seção intitulada “Os ambientes são seus para definir”

Toda organização começa com três ambientes pré-criados — dev, staging e production — e você pode criar, renomear e excluir os seus próprios, até 12. Um ambiente de QA, um par por região, um canary — o que combinar com o jeito como você faz deploy.

Gerenciar ambientes (criar, renomear, reclassificar, excluir) é uma ação de Admin para cima. Você não pode excluir um ambiente enquanto chaves de SDK ativas ainda se autenticam contra ele — um ambiente que os seus apps ainda estão lendo não pode ser excluído debaixo deles.

A classe de produção — não o nome

Seção intitulada “A classe de produção — não o nome”

O que faz um ambiente ser “produção” não é o nome — é a classe de produção, uma caixa de seleção que um Admin marca. A classe é o que aciona as proteções:

  • Escrever flags ali exige um papel mais alto. Developers ligam e desligam ambientes fora de produção à vontade o dia todo; um ambiente de classe de produção aceita escritas diretas apenas de Admins e Owners. (Developers ainda podem propor mudanças em produção para um colega aprovar — veja Papéis e segurança.)
  • O painel o estiliza de forma chamativa, para que ninguém edite produção achando que é staging.

Como é uma classe e não um nome, você pode ter vários ambientes de classe de produção — digamos, production-eu e production-us — e cada um recebe as mesmas proteções. E marcar um ambiente como classe de produção é, em si, um ato auditado de nível Admin, porque muda quem pode escrever ali.

Projetos

Seção intitulada “Projetos”

Flags, os alvos dos segmentos e chaves de SDK vivem dentro de um projeto. Uma organização pode ter muitos — um por app, um por time, do jeito que você dividir o seu trabalho. Cada projeto tem a sua própria lista de flags, o seu próprio arquivo e as suas próprias chaves de SDK.

O acesso a projetos é uma lista de permissões

Seção intitulada “O acesso a projetos é uma lista de permissões”

Admins e Owners veem todos os projetos. Viewers e Developers veem apenas os projetos que lhes foram concedidos — o acesso é uma lista de permissões por membro, gerenciada por Admins.

Um detalhe que vale conhecer para nunca surpreender você: um projeto que um membro não recebeu responde como se não existisse — um não-encontrado, não um erro de “sem acesso”. Um membro não consegue enumerar nomes de projetos que não lhe foram dados. Se um colega disser que um projeto sumiu, verifique as concessões de acesso dele antes de qualquer outra coisa.

Para onde ir agora

Seção intitulada “Para onde ir agora”