組織が複数の Jira インスタンスを使用して多数のユーザー向けの環境を実現している場合、これらのインスタンスを 1 つの Jira Data Center インスタンスに統合することをお勧めします。これにより、あらゆる大企業が Jira に求める、管理機能、相互運用、高可用性、およびパフォーマンスを実現できるようになります。 

ただしアトラシアンでは、統合や移行はすべての組織で利用可能なものではないことも理解しています。このような場合、インスタンスのフェデレーションを行うことで、インスタンスの接続性や相互運用性を確保したうえで自律性を実現することができます。本ガイドでは、フェデレーションしたインスタンスの健全性を維持するために役立つ、さまざまな機能とプラクティスについて説明します。

フェデレーションに繋がる状況

最初に、フェデレーションにつながる状況について見てみましょう。当社のお客様に関して言えば、複数の Jira インスタンスの実行が必要となる 4 つの主な理由を識別できます。

• Jira のボトムアップ成長: Jira の低価格ポイントや実用的な価値により、最初は 1 チームで Jira を開始して、その後、独自のサーバー インスタンスを回転させる新しいチームで組織全体へ広げるという場合が良くあります。

• 合併や買収: 他の組織の買収や合併により、1 つの組織に複数の Jira サーバーが存在する場合があります。
• 独立した IT 組織: 組織の異なる部門は、独自の IT 組織を運営している場合があります。このことは、他部門とのプロセスや協力が行われてから、後の段階で統合できる並列 Jira システムにつながります。
• 意図的なフェデレーションのセットアップ: 以下の理由の 1 つまたは複数が、フェデレーテッド Jira システムの意図的なセットアップにつながる場合があります。

フェデレーション環境をセットアップする理由

専用インスタンスの意図的なセットアップへ掘り下げることで、顧客、パートナー、および自分たちの IT 組織の方法をまとめ、これらを実行するためのいくつかの理由を特定することができます。

• パブリック / プライベート Jira: Jira はパーミッション スキームやユーザー グループを通じて識別されたグループのみが特定のコンテンツにアクセスできるようにする機能を提供しています。ただし、アトラシアン自体を含め、多くの顧客は、社内コンテンツ (開発など) をファイアウォール内の別のインスタンスで実行することを好みます。その場合、外部コンテンツ (サポート / パブリック機能のリクエストなど) をホストする専用インスタンスをセットアップして、顧客とパートナーがアクセスできるようにします。
• 異なるレベルの複雑性: 少ないユーザーを対象とし、かつ複雑性の主な原因となっている 1 つのプロジェクトがある JIRA インスタンス (顧客フィールド、ワークフローやカスタマイズなど) の例を見てみましょう。この複雑性が全体的なパフォーマンスと JIRA インスタンス全体の安定性に影響するのを防ぐため、プロジェクトを専用 Jira サーバーへ移行するのが合理的です。
• 新機能へのアクセスと安定性の比較: 特定のチームの生産性が新機能へのアクセスの影響を大きく受ける可能性があるものの (例: アジャイル チームの新しい Jira Software 機能)、組織の他の部分は新機能全体で安定した特定のワークフローと価値システムを実装している場合があります。このような場合は、安定している旧バージョンの本番環境インスタンスを実行しながら、アーリー アダプター向けに生産的な Jira Server を別途運用するオプションを検討できます。

• 外部顧客要件: 一部の顧客は、組織に対し、他のインフラストラクチャと物理的に離れたシステム上で自分たちのプロジェクトを実行し、データをホストするよう要求する場合があります。これらの要件は、国防契約などの機密プロジェクトの場合に当てはまります。
• 構成や設定が異なる: Jira の構成機能は、アプリケーションのほとんどすべての懸念に対してスキーマを提供することで有名です。これにより、1 つのインスタンスで多種多様な異なるプロジェクトをホストすることができます。このことは、独自のブランド化や異なる設定を持つことができるよう、1 つのプロジェクトに専用インスタンスが必要とする便利です。これらには、異なる優先順位や解決策、異なる管理者のセット、時間追跡機能を使用するかどうか、およびその他すべての Jira のグローバル設定が含まれます。 
• 法的要件: データのプライバシー保護法、サーバーの管轄権や政府の調査などにより、特定の Jiraプロジェクトに対して別の管轄権に専用サーバーを置くこと決定する場合があります。このような場合の例として、欧州の企業が、個人の権利と同じ保護レベルでデータ プライバシー法を提供していない EU 外の国でホストされているサーバー上に EU 市民の個人情報データを保護できないことがあります。 
• 内部サービスとしての Jira: 一部の大企業の顧客では、Jira をサービスとして社内で提供しています。そのような組織には標準構成があり、Jira システムをリクエストする各事業部門に対してそれらの構成を複製することができます。各システムには事業部門固有の管理者がおり、集中 IT 組織はシステム管理のコンピテンシーを保持します。 
• リスクとダウンタイムの分散: インスタンスが大きくなると、アップグレードにかかる時間も長くなります。そのため、すべてのユーザーが Jira サービスを使えなくなる時間を短縮するためにできることの 1 つとして、インスタンスのサイズを分割して縮小することがあります。これにより、8 時間のアップグレード ダウンタイムを分割し、4 つのシステムに対して 2 時間のダウンタイムに調節することで、それぞれのダウンタイムがユーザーに与える影響を減らすことができます。 

複数の Jira インスタンスの管理における推奨事項

Jira インスタンスのフェデレーションは、企業顧客の間では非常に一般的です。アトラシアンが過去に行った調査では、数百もの顧客が組織内で 3 台以上の Jira サーバーを運用していました。その結果、フェデレーテッド環境を持つ顧客は珍しいものではなく、大きなコミュニティの一部となります。そのため、アトラシアンでは、フェデレーテッド Jira インタンスの管理や相互運用性を顧客が簡単に行えるようにする機能を開発し、継続的に実装しています。

フェデレーション機能

Jira、Confluence、および、Atlassian Stack 全体の強力な機能の 1 つが、Atlassian 製品を連携させられることです。この優れた例の 1 つに、Confluence ページ内で Jira 課題を動的にリスト表示できる機能があります。いまた、この同じ機能により自立した Jira インスタンスの統合が可能になります。

そのため、すべてのバージョンにアプリケーション リンクが含まれている限り、Jira サーバーは全く同じバージョンを実行する必要はありません。これにより、異種環境における相互運用性 (例:フェデレートを行う理由「新機能へのアクセス」を参照) が大幅に容易になります。

一言でいえば、アプリケーション リンクの目標は、インスタンス間のリンクと課題の統合を、同一インスタンス内のプロジェクト間の統合のように簡単にすることです。そのため、Jira インスタンス間のアプリケーションリンクが設定されると、以下に説明する統合機能が利用可能になります。

統合されたアクティビティ ストリーム

アクティビティ ストリームには、作業中のインスタンスだけでなく、接続されている Jira やその他のアトラシアン製品インスタンス (例: Confluence や FishEye) からの更新も表示されます。たとえば、2 つの会社が 1 つのプロジェクトに携わっており、自分たちの Jira インスタンスをリンクさせることで、統合されたアクティビティ ストリームを通じ、パートナーの Jiraでの作業の新しいステータス変更を適用して更新することができます。

統合レポート ダッシュボード

リンクされた信頼できる別の Jira インスタンスからデータを取得するガジェットは、Jira ダッシュボードに追加できます。これにより、関連するすべての事例の概要を統一的に報告できます。標準ガジェットの他に、ガジェットを追加することもできます。1 つのガジェットのみで別のプロジェクトの特定の指標を別のインスタンスで報告することから、すべての Jira システムのすべてのプロジェクトのレポートを実行する集中インスタンスをフェデレーション内に 1 つ持つことまで、アプリは無限にあります。

リモート課題リンク

関連する Jira の課題を結びつけるには、課題のリンクが不可欠です。リモート リンクがあれば、他のローカル プロジェクトへの課題の依存関係やその他の関係を追跡できるだけでなく、他のインスタンスのリモート プロジェクトとの関係も追跡できます。

アプリケーションナビゲーター

アトラシアン製品のアドレスを覚える必要はもうありません。アプリケーション ナビゲーターのヘッダーを使用すると、Jira インスタンスや、連携する他のアトラシアン製品をすばやく切り替えられます。

Jira 課題のコピー (Atlassian Labs 製、サポート対象外)

Atlassian Labs は Jira から Jira への課題コピーを開発しました。これにより、ユーザーはある Jira インスタンスから別の Jira インスタンスに課題をコピーできます。現在も Atlassian Labs にあり、Atlassian Marketplace で入手できます。よりすっきりとしたわかりやすいユーザー インターフェースを備え、強化されたより多くのカスタム構成やユーザー マッチング アルゴリズムをサポートしています。このアドオンはアトラシアンではサポートされていません。現在のところ機能していても、Atlassian Labs のステータスにあるため、重要なプロセスに組み込むことはおすすめしません。

フェデレーテッド検索

複数のインスタンスにまたがる検索は、すぐに使える Jira インストールの一部ではありませんが、ALM の Jira Client を使えば可能です。このアプリは、Jiraを使用してオフラインで作業ができるように設計されたデスクトップ アプリです。これにより、無制限の Jira インスタンスへの接続を確立できます。この接続が確立されると、検索クエリはさまざまなシステムにおいて自動で実行されます。

フェデレーテッド インスタンスの管理

以下のセクションでは、フェデレーテッド Jira インスタンスの効率的な管理に利用できる Jira の機能について説明します。

集中ユーザー管理

Jira は、単一ソースのユーザー管理、グループ定義、および認証 (SSO) を行う複数の方法を提供しており、複数の Jira インスタンスや他のアトラシアン製品で以下からデータを取得することができます。

• Crowd: 組織のアプリや開発ツール用にシングル サインオンを使用した集中 ID 管理を提供する、アトラシアン専用の製品。詳細は「ユーザー管理のために Crowd に接続する」の章をご覧ください。Jira から Crowd へユーザー ディレクトリを移行する場合は、「Jira から Crowd へのユーザーのインポート」をご覧ください。
• LDAP: 分散ディレクトリ情報の保存や管理についての事実上の標準です。LDAP ディレクトリへの接続方法の詳細についての Jira ドキュメントを参照してください。

複数の Jira システムや他のアトラシアン製品がどのように相互運用され、一元化されたユーザー管理を実現するかについてのさまざまなシナリオの概要については、「ユーザー管理で可能な設定のダイアグラム」の図をご参照ください。

権限スキームの調整

また、ユーザー グループに対する単一のソースを持つことができることため、複数のシステム全体での権限の調整が容易になります。プロジェクト管理者、システム管理者、社外および社外などのグループを一元化してから、Jira のローカル権限に割り当てることができます。

ワークフロー共有

ワークフロー共有機能を使用すると、Atlassian Marketplace を通じてチームのワークフローを組織の別の Jira インスタンス上の他のチームと共有したり、他の組織の外部関係者と共有したりできます。この機能によって、他のユーザーが公開したワークフローを簡単に使用したり、自分の組織でワークフローをステージング環境から本番環境に移行したりできます。また、古い Jira リリース用のアプリとしても提供されています。

移行、マージおよび分割

フェデレーテッド環境では、Jira の複数のインスタンスで複数のプロジェクトが実行します。特定の状況では、関与するインスタンスの数を置き換えたり、プロジェクトをそれらの間で動かすことで、フェデレーションの状況を変更することが望ましい場合があります。これは、インスタンスのマージや分割、およびプロジェクト移行を通じて実現できます。  

• プロジェクトを別のインスタンスに移行する - CSV インポート: 1 つのプロジェクトだけを移行する場合は、CSV インポーターを使用するのが簡単です。

1. 1. ターゲット インスタンスでプロジェクトを作成する。 
   2. ソース プロジェクトの課題を CSV 形式でエクスポートする。 

   3. CSV インポーターを使用してターゲット システムへインポートし、ウィザードを使用してメタデータをターゲット インスタンス構成に合わせる。

      CSV インポートでは、課題データ自体のみが移行されることにご注意ください。アクティブなオブジェクトに保存されているアプリ データは移行されません。

      詳細については、「CSV からのデータのインポート」をご参照ください。

• マージ / 移行 - プロジェクトのインポート: 1 つのプロジェクトを移行する方法の 1 つは、ソース システムでエクスポート機能を使用してから、ターゲットの Jira インスタンスでプロジェクトのインポートを使用することです。「プロジェクトをバックアップから復元する」をご参照ください。
• インスタンスの分割 - 完全な XML バックアップ復元: 復元機能を使用すると、バックアップ/復元手順で Jira インスタンスのクローンを作成できます。詳細な手順については、「Jira アプリケーションの分割」をご参照ください。

1. 1. 既存のシステムと同じバージョンで新しい Jira Data Center を設定します。 

      これには、新しい Data Center ライセンスが必要です。 

   2. ソース システムのフル バックアップを実行します。 

   3. バックアップ ファイルを新しい Jira インスタンスにインポートします。
   4. ソース インスタンスとターゲット インスタンスから削除する重複プロジェクトを選択します。

   5. このオプションは、ターゲット インスタンスが空の場合にのみ適用されます。

      同じサーバー上で複数の Jira インスタンスを実行することは可能ですが、企業で Jira を使用する場合は専用のハードウェア / VM をおすすめします。

• インスタンスの分割 - DB / ファイルシステム レベル: 一部のアプリは、標準 XML エクスポートを通じてエクスポートできない方法で Jira データベースを使用する場合があります。
  
  • 別の Jira サーバーをセットアップしてアプリケーション サーバー、データベースおよびインストール / ホーム ディレクトリをレプリケートします。詳細な手順については、ステージング環境を参照してください。 
  • ここに記載されている手順は基本的に、上記の「インスタンスの分割 - フル XML バックアップの復元」と同じですが、今回はネイティブのデータベース バックアップ ツールを使用します。

構成管理

Jira インスタンスのフェデレーテッド システムが増えると、これらのシステムを一元管理する必要性も高まります。お客様はさまざまな方法を実施することで構成管理を実現しています。

• バージョン管理システム: Subversion や GIT などの VCS を使用して、構成 XML やテンプレートなどのファイルに対する変更をトラッキングした後、ステージング環境や本番システムにそれぞれデプロイすることができます。このアプローチによってロールバック変更が可能となり、すべてのインスタンスのすべての構成ファイルに一元的な概要を持つことができます。
• 構成管理ツール: 当社のお客様の多くは、IT システム、バージョンなどをトラッキングするため、構成管理ソフトウェアを使用しています。たとえば、Puppet と puppet-Jira アプリ の組み合わせなどがあります。 
• 継続的デプロイ: Bamboo などの CI アプリケーションを使用すると、Jira のステージング/本番システムへ構成の変更を自動または手動でデプロイできます。
• アトラシアン ラボの Jira ワークフロー共有プラグイン (サポート対象外)。上記の「マージ/分割」セクションでも説明しています。ワークフローの維持や構成を一元的に行い、複数の Jira システム全体で共有するために使用できます。

分散環境のアジャイル ボード

分散環境で作業する必要がある場合は、リモートの Cloud や Server の Jira インスタンスからの課題を 1 つのアジャイル ボードに統合するのに WatchTower for Jira が役立ちます。WatchTower を使用すると、Jira のアジャイル ボード上でリモート インスタンスの課題を一元的に管理できます。WatchTower で、フェデレーション環境にまたがる複数のプロジェクトでコンテキストの切り替えや全体像の把握にかかる時間を節約できます。

インスタンスを越えたプロジェクトの同期化

一部のシナリオでは、Jira システムが連携され、類似したエンティティを処理している場合、1 つのシステムでの操作がもう片方のシステムに影響を与えるようにするのが望ましい場合があります。これは機能としては提供していませんが、アプリとスクリプトを使用することで実現できます。

• Backbone Issue Sync for Jira (サポート元: K15t)
  Backbone Issue Sync for Jira は、異なる Jira インスタンス間で課題データを同期します。柔軟かつ確実な方法で、部署や B2B の境界を超えて Jira プロジェクト データを簡単に同期できます。 

• Power Scripts - Jira ワークフローの自動化 (サポート元: Appfire)

  Power Scripts アプリは、管理者が新しい機能を作成できるよう、Jira に新しいスクリプティング レイヤーを提供します。フェデレート Jira 環境での同期およびシステム横断型ワークフローのソリューションとしてマーケットプレイスで紹介されています。 
• Enterprise Mail Handler for Jira (JEMH) (サポート元: The Plugin People)
  Enterprise Mail Handler for Jira は、本来、受信メールを処理する高度な機能を提供するように設計されたアプリです。これには、Jira アカウントを持たないユーザーや、複数のメール エイリアスを使用するユーザーとのやり取りが含まれます。プロジェクトやフィールド マッピングを通じて、異なるインスタンス間で課題を同期、更新するためにも使用できます。たとえば、課題がインスタンス B で特定の状態にトランジションする場合にインスタンス A で課題を自動作成できます。ただし、このような自動化をセットアップする場合、両方のインスタンスで同時に課題が更新されると無限ループが発生する可能性があるため、丁寧なテストを行う必要があります。
• ScriptRunner (サポート元: Adaptavist)
  多くのお客様が Jira のスクリプト機能を増強するために ScriptRunner を使用しています。このアプリは、Groovy、Python (jython)、Ruby (JRuby) および JavaScript などの言語での入力に対応しています。 

複数のインスタンスのアップグレード

Jira 管理マニュアルに記載されているアップグレードの手順を手動で繰り返さずに済むようにするために、プロセスを部分的または完全に自動化する下記のような方法があります。

• 自動バックアップ: Jira コマンドライン インターフェイスを使用して Jira からデータをエクスポートできます (ira CLI は、自動化テストにも非常に便利です)。
• Symlinks: システム管理者はインストール ディレクトリのみを操作する代わりに、各 Jira バージョン用にディレクトリを管理できます。新しいバージョンがインストールおよび変更されると、リンク記号が変更され、新しいバージョンのフォルダーをポイントするようになります。これは、アトラシアン社内で実績のある方法です。

高可用性が要求される Jira インスタンスでは、Jira のステージング サーバー設定を使用することも推奨されます。ステージング サーバーに個別のライセンスは必要ありません。

複数のインスタンスの HA / フェイルオーバーの計画

1 つの Jira Data Center での Jira インスタンスのフェデレーションにより、インスタンスに対して異なる可用性要件を設定することができます。複数の Jira インスタンスにはロード バランサー (HA モードで実行していることを条件とする) など、さまざまなインスタンスに同じツールを活用することもできます。

詳細については、「Jira のフェイルオーバー ガイド」をご参照ください。

その他のリソース