組織が複数の 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 ラボ、サポート対象外)

アトラシアン ラボ は、Jira インスタンスから別のインスタンスへ課題をコピーできる Jira から Jira への課題コピーを開発してきました。現在まだアトラシアン ラボ内にあり、Atlassian Marketplace で利用できます。ユーザー インターフェイスの理解をより明確かつ容易にし、ユーザー照合アルゴリズムにおけるより多くのカスタム構成や機能強化をサポートしています。このアドオンはアトラシアンではサポートされていません。また、現在のところ、機能しているように思われるかもしれませんが、アトラシアン ラボのステータスとなっているため、依存対象となるプロセスへの組み込みはお勧めしません。

フェデレーテッド検索

複数インスタンスにわたる検索は Jira インストールへの組み込み機能には含まれていませんが、ALM の Jira Client で実現することができます。このアプリは、Jira でのオフライン作業を実現するために設計されたデスクトップ アプリケーションです。これを使用することで無制限の Jira インスタンスへの接続を有効化し、接続の確立後は検索クエリをさまざまなシステムにわたって自動的に実行できます。

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

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

集中ユーザー管理

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

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

複数の Jira システムおよび/あるいはその他のアトラシアン製品を総合運用し、一元化されたユーザー管理を実現する方法に関するさまざまなシナリオの概要については、「ユーザー管理で可能な設定のダイアグラム」図を参照してください。 

権限スキームの調整

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

ワークフロー共有

ワークフロー共有機能は、チームのワークフローを異なる Jira インスタンスを使用している組織内の他のチームと共有する場合や、Atlassian Marketplace を介して他組織の外部関係者と共有する場合に有用な機能です。この機能を使用することで、他の人が公開したワークフローを簡単に使用したり、組織でワークフローをステージング環境から本番環境に移動したりすることができます。また、古い Jira リリースではアプリとして提供されます。

移行、マージおよび分割 

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

最初にテストを実施してください! 以下のすべての手順について、本番システムに触る前にまず、ステージング環境でこの手順を実行することを強くお勧めします。

• • プロジェクトを別のインスタンスに移行する - CSV インポート: 1 つのプロジェクトのみを移行する場合、CSV インポーターを使用することをおすすめします。
  1. 1. ターゲット インスタンスでプロジェクトを作成する。 
     2. ソース プロジェクトの課題を CSV 形式でエクスポートする。 
     3. CSV インポーターを使用してターゲット システムへインポートし、ウィザードを使用してメタデータをターゲット インスタンス構成に合わせる。

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

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

• • 統合 / 移行 - プロジェクトのインポート: 1 つのプロジェクトを移行する方法の 1 つとして、ソース システムでエクスポート機能を使用してから、ターゲットの Jira インスタンスでプロジェクト インポートを使用する方法があります。 
  1. 1. 2 つのインスタンスが Jira およびアプリの同じバージョンを実行していることを確認します。 
     2. また、ソース システム内のプロジェクトに関連するカスタム フィールド、ユーザー グループ、エンティティ (優先順位やステータスなど)、およびスキームが、同じ命名法で、ターゲット システム内に存在することも確認する。
     3. ソース システムからのフルまたは部分 XML エクスポートを実行する。
     4. ターゲット システムに XML ファイルをインポートする。 

「バックアップからのプロジェクトの復元」を参照してください。 

• • インスタンスの分割 - XML バックアップの復元: 復元機能を使用すると、バックアップ / 復元手順を通じて Jira インスタンスの複製を作成できます。 
  1. 1. 既存のシステムの同じバージョンを使用して新しい Jira Data Center をセットアップします。これには、新しい Data Center ライセンスが必要です。 
     2. ソース システムのフル バックアップを実行します。 
     3. バックアップ ファイルを新しい Jira インスタンスにインポートします。
     4. ソース インスタンスとターゲット インスタンスから削除する重複プロジェクトを選択します。
     5. このオプションは、ターゲット インスタンスが空の場合にのみ適用されます。 

詳しい説明については、「Jira アプリケーションの分割」を参照してください。 

同じサーバーで複数の Jira インスタンスを実行することは可能ですが、Jira のエンタープライズ使用には専用ハードウェア / VM をお勧めします。

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

構成管理

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

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

分散環境におけるアジャイル ボード

分散環境で作業する必要がある場合、WatchTower for Jira を使用すると、リモートの Cloud または Server の Jira インスタンスから単一のアジャイル ボードに課題を統合することができます。WatchTower では、Jira のアジャイル ボードでリモート インスタンスの課題に取り組むための単一の管理ポイントが提供されます。WatchTower では、複数の環境にわたる複数のプロジェクトで、コンテキストの切り替えや全体像の把握にかかる時間を節約できます。 

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

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

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

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

Jira 管理マニュアルに記載されているアップグレード手順を手動で繰り返し実行する代わりに、プロセスの一部または全部を自動化する方法を利用できます。

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

高可用性要件のある Jira インスタンスでは、Jira にステージング サーバー セットアップを使用することをお勧めします。ステージング サーバーに別途ライセンスは必要ありません。 

アプリケーション リンクで説明したように、Jira インスタンスが同じバージョンを実行していなくてもアプリケーション リンクを有効化できます。 

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

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

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

その他のリソース