環境とプロジェクト
FortressFlag のすべては 2 つの軸で整理されます。プロジェクトは flag をコードベースやプロダクトごとに分け、環境は各 flag の値をデプロイ段階ごとに分けます。dev ビルドのアプリは dev 環境から new-checkout を読み、出荷済みのアプリは本番環境から読みます。同じ flag、独立した値です。
環境はあなたが定義する
Section titled “環境はあなたが定義する”すべての組織は 3 つのシードされた環境（dev、staging、production）から始まり、最大 12 個まで独自の環境を作成、改名、削除できます。QA 環境、リージョンごとのペア、canary など、あなたのデプロイのやり方に合うものを。
環境の管理（作成、改名、再分類、削除）は Admin 以上の操作です。稼働中の SDK キーがまだその環境に対して認証している間は、環境を削除できません。アプリがまだ読んでいる環境を、その足元から削除することはできないのです。
本番クラスは名前ではない
Section titled “本番クラスは名前ではない”環境を「本番」にするのは名前ではなく、Admin が設定するチェックボックス、本番クラスです。このクラスが安全装置を駆動します。
- そこへの flag の書き込みには、より高いロールが必要です。Developer は非本番環境を一日中自由に切り替えられますが、本番クラスの環境は Admin と Owner からの直接書き込みだけを受け付けます。（Developer は本番環境の変更を提案して、チームメイトに承認してもらうことはできます。ロールと安全性を参照してください。）
- ダッシュボードはそれを目立つスタイルで表示します。staging だと思って本番環境を編集する人が出ないように。
名前ではなくクラスなので、本番クラスの環境を複数持てます。たとえば production-eu と production-us で、どちらも同じ安全装置を得ます。そして環境を本番クラスに指定すること自体が、監査される Admin レベルの行為です。誰がそこに書き込めるかを変えるからです。
プロジェクト
Section titled “プロジェクト”flag、セグメントの対象、SDK キーはプロジェクトの中に住みます。1 つの組織は多くのプロジェクトを持てます。アプリごと、チームごと、あなたの仕事の切り方に合わせて。各プロジェクトは独自の flag 一覧、独自のアーカイブ、独自の SDK キーを持ちます。
プロジェクトへのアクセスは許可リスト
Section titled “プロジェクトへのアクセスは許可リスト”Admin と Owner はすべてのプロジェクトを見られます。Viewer と Developer は、付与されたプロジェクトだけを見ます。アクセスはメンバーごとの許可リストで、Admin が管理します。
驚かされないよう知っておく価値のある細部が 1 つあります。メンバーに付与されていないプロジェクトは、存在しないかのように応答します。「アクセス権がない」というエラーではなく、not-found です。メンバーは与えられていないプロジェクト名を列挙できません。チームメイトがプロジェクトが見当たらないと言ったら、何よりも先にそのアクセス付与を確認してください。