多くの開発プロジェクトを抱えている企業の場合、複数の FitNesse wiki を作成する必要があります (プロジェクト/製品ごとに 1 つ) か、すべての大きな wiki 内にそれらすべてを含める必要がありますか?
1 つの大きな Wiki の利点は、社内の他の製品に簡単にリンクできることと、FitNesse のすべてのテストを 1 か所で行えることです。
または、複数の wiki の利点は、テストの自動化を複数のサーバーに分割することが容易になること、プロジェクト ブランチ/タグに沿って wiki を分岐することが容易になることです。
私は、これら 2 つの可能性の長所と短所、またはよく考え抜かれた代替手段に興味があります (たとえば、「ウィキのルートを何らかの方法で組み合わせるだけではない」など)。
突き詰めると、すべては管理上の問題に帰着するようです:
利用可能なサーバーの数と、それらを管理するのは誰ですか?
1 つの中央サーバーとは、要求に関して (すべてのプロジェクトのすべての開発者がかなり定期的に多くのクエリを作成できる)、「サーバー上」の FitNesse 関連の計算に関して、サーバーが負荷を引き受けることができることを意味します。
もう 1 つの基準は、可視性です。あなたの開発プロジェクトは、お互いの FitNesse 指標を見る必要がありますか? 「政治的」な理由から、これらの指標のいくつかは、他のプロジェクトでいつでも見られることが常に歓迎されているとは限りません! 一部のプロジェクト マネージャーは、彼らをベストの近くに置いて、公式のコミュニケーションを管理したいと考えるかもしれません。
実際、FitNesses wiki が内部ツールとして各チームによって管理されているのは後者の理由によるものです。各プロジェクトのグローバル ドキュメントを管理するために、別のグローバル wiki ( Confluanceに基づく) があります。これらの一般的な wiki は、内部の FitNesse wiki データの一部を抽出する場合があります。