Federating JIRA - managing multiple instances

If your organization uses multiple instances of JIRA to handle the load of your users, we recommend that you consolidate those instances into a single JIRA Data Center instance. This will provide you with the administrative features, interoperability, high availability, and performance every large organization needs from JIRA. 

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

本ガイドに記載されているアプリ (アドオン) の一部は、トップ ベンダーが開発したものではありません。また、一部の方法はお客様の組織のセットアップに適していない場合があります。

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

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

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

  • Mergers & acquisitions: Through acquiring or merging with other organizations, a company can find itself managing several JIRA servers.
  • 独立した IT 組織: 組織の異なる部門は、独自の IT 組織を運営している場合があります。このことは、他部門とのプロセスや協力が行われてから、後の段階で統合できる並列 JIRA システムにつながります。
  • 意図的なフェデレーションのセットアップ: 以下の理由の 1 つまたは複数が、フェデレーテッド JIRA システムの意図的なセットアップにつながる場合があります。

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

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

  • パブリック / プライベート JIRA: JIRA はパーミッション スキームやユーザー グループを通じて識別されたグループのみが特定のコンテンツにアクセスできるようにする機能を提供しています。ただし、アトラシアン自体を含め、多くの顧客は、社内コンテンツ (開発など) をファイアウォール内の別のインスタンスで実行することを好みます。その場合、外部コンテンツ (サポート / パブリック機能のリクエストなど) をホストする専用インスタンスをセットアップして、顧客とパートナーがアクセスできるようにします。
  • 異なるレベルの複雑性: 少ないユーザーを対象とし、かつ複雑性の主な原因となっている 1 つのプロジェクトがある JIRA インスタンス (顧客フィールド、ワークフローやカスタマイズなど) の例を見てみましょう。この複雑性が全体的なパフォーマンスと JIRA インスタンス全体の安定性に影響するのを防ぐため、プロジェクトを専用 JIRA サーバーへ移行するのが合理的です。
  • Access to new features vs stability: An organization might have a situation where a specific teams' productivity is heavily influenced by their access to new features (e.g. new JIRA Software features for Agile teams), while other parts of the organization have implemented stable, specific workflows and value system stability over new features. In this case, it might be a viable option to run a stable, conservative, production instance while operating a separate productive JIRA server for early adopters.

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

フェデレーションの例として、アトラシアンがさまざまな目的でどのように専用インスタンスを配備しているかを紹介します。

名前 目的 専用インスタンスで実行する主な理由 アプリケーションリンクの例

JAC

新機能要件、変更リクエストやバグを含む、一般向け課題管理インスタンス。ここでの最適な機能は、顧客が課題に投票できる機能です。 パブリック / パブリック JAC 課題を JDOG に関する開発の課題とリンクさせる。
SAC 外部のサポート インスタンス。課題には機密情報が含まれる場合があるため、課題は報告者 (サポート申請者) とアトラシアンの従業員のみが参照できます。 外部顧客要件、パブリック/プライベート Linking between サポートの顧客に表示される) および JDOG (アトラシアンにのみ表示される) をリンクさせる。
JDOG JIRA チームの試験運用サーバー - 最先端の機能に関するイメージを検証します (JIRA は当社の製品ですが、あなたが着想するため、これは非常に特異なケースです)。 新機能へのアクセス JAC と SAC をそれぞれバックリンクさせる
HelloJ マーケティングから調達および社内 IT に至るビジネス プロセスを実行する社内 JIRA。 パブリック / パブリック


Recommendations for managing multiple JIRA instances

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

フェデレーション機能

JIRA、Confluence、および、Atlassian Stack 全体の強力な機能の 1 つが、アトラシアン製品を連携させられることです。この優れた例の 1 つに、Confluence ページ内で JIRA 課題を動的にリスト表示できる機能があります。いまた、この同じ機能により自立した JIRA インスタンスの統合が可能になります。そのため、すべてのバージョンにアプリケーションリンクが含まれている限り、JIRA サーバーは全く同じバージョンを実行する必要はありません。これにより、異種環境における相互運用性 (例: フェデレートを行う理由「新機能へのアクセス」を参照) が大幅に容易になります。

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

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

Activity streams not only show updates from the instance you are on but also from connected JIRA or other Atlassian product instances (e.g. Confluence or Fisheye). For example, two companies working together on a project and linking up their JIRA instances could be updated with new status changes of work at their partner's JIRA through a unified activity stream.

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

JIRA ダッシュボードには、リンクされ、信頼されている他の JIRA インスタンスのデータを取り込むガジェットを追加することができます。これにより、すべての関連インスタンスの統合レポート概要が有効になります。たとえば、アトラシアンでは、情報ラジエーターを使用して、内部および外部 JIRA インスタンス全体でリアルタイム レポートを表示します。標準ガジェットの次に、追加ガジェットを加えることもできます。別のインスタンスの別のプロジェクトの特定のメトリックを報告する 1 つのガジェットから、すべての JIRA システムのすべてのプロジェクトのレポートを実行する、フェデレーションでの 1 つの集中インスタンスまで、アプリケーションは無限にあります。 

Linking issues is crucial to connecting relevant JIRA issues. With remote links, you can not only track dependencies and other relations of issues to other local projects, but to remote projects in other instances as well. See our example about how we connect issues in JAC (JIRA.Atlassian.com) with internal development tickets in our JDOG instance.  

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

アトラシアン製品のアドレスを覚える必要はなくなりました。アプリケーションナビゲーターヘッダーを使用することで、JIRA インスタンスや、連携しているその他のアトラシアン製品をすばやく切り替えることができます。 

多くの場合、特定の製品の開発用に社内 JIRA インスタンスで 1 つのプロジェクトがあり、次いで、その製品をサポートするために外部インスタンスに 1 つのプロジェクトがあります。プロジェクト リンクを使用することで、これらの 2 つのプロジェクト間の接続を容易にすることができます。例えば、JIRA2 を示す JIRA1 内のアクティビティ ストリームは、接続されているプロジェクトの関連する更新を自動的に表示します。

JIRA Issue Copy (by Atlassian Labs, not supported)

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

フェデレーテッド検索

複数のインスタンスにわたる検索は、JIRA インストールのすぐに使用可能なオプションではありませんが、ALM の JIRA クライアントを通じて実現することができます。このプラグインは、JIRA でのオフライン作業を可能にするよう設計されたデスクトップ アプリケーションです。これを使用することで無限の JIRA インスタンスへの接続を確立できます。この接続が確立されると、検索クエリはさまざまなシステムすべてで自動的に実行されます。

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

The following sections describe JIRA features that you can use to efficiently administer a federated JIRA instance:

集中ユーザー管理

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

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

権限スキームの調整

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

Workflow sharing

The Workflow Sharing feature allows you to share your team's workflow with other teams in your organization on different JIRA instances, or external parties in other organizations via the Atlassian Marketplace. This feature allows you to easily use workflows that other people have published, or to move a workflow from staging to production in your own organization. It is also provided as a plugin for older JIRA releases.

移行、マージおよび分割 

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

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

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

(warning) CSV インポートは課題データ自体のみをインポートします。アクティブ オブジェクトに保存されているプラグイン データは持ち越されません。

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

    • Merge / Migrate - project import: One way to migrate a single project is to use the export function in the source system and then use project import in the target JIRA instance. 
      1. 2 つのインスタンスが JIRA およびプラグインの同じバージョンを実行していることを確認する。 
      2. また、ソース システム内のプロジェクトに関連するカスタム フィールド、ユーザー グループ、エンティティ (優先順位やステータスなど)、およびスキームが、同じ命名法で、ターゲット システム内に存在することも確認する。
      3. ソース システムからのフルまたは部分 XML エクスポートを実行する。
      4. ターゲット システムに XML ファイルをインポートする。 

(warning) プロジェクトの XML エクスポートには、プラグイン固有のすべてのアクティブ オブジェクト (Agile ランキングなど) のエクスポートは含まれません。JRA-28748 (Project Imports should include GreenHopper data) をご参照ください。

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

    • Splitting an instance - full XML backup restoration: Using the restoration feature, it is possible to clone a JIRA instance through a backup/restore procedure. 
      1. 既存のシステムの同じバージョンを使用して新しい JIRA サーバーをセットアップします。(info) これには、新しい JIRA ライセンスが必要です。 
      2. ソース システムのフル バックアップを実行します。 
      3. バックアップ ファイルを新しい JIRA インスタンスにインポートします。
      4. ソース インスタンスとターゲット インスタンスから削除する重複プロジェクトを選択します。
      5. このオプションは、ターゲット インスタンスがの場合にのみ適用されます。 

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

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

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

構成管理

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

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

JIRA Auditor アドオンは、JIRA の構成変更に関する監査ログを保持します。複数の管理者が同一インスタンスに変更を加える場合には、特に重要です。

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

If you need to work in distributed environment WatchTower for JIRA can help you to consolidate issues from remote Cloud and Server JIRA instances into one single agile board. WatchTower gives you a single point of control to work with issues from remote instances on agile board in your JIRA. Watchtower saves you time on context switching and gathering complete picture for several projects spread over federated environment. 

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

In some scenarios,when JIRA systems are integrated and deal with similar entities, it might be desirable to have actions in one system affect another. This is not an out-of-the-box feature but can be achieved through the use of plugins and scripting:

    • Backbone Issue Sync for JIRA, supported by K15t Software GmbH
      The Backbone Issue Sync for JIRA  synchronizes issue data between different JIRA instances. Synchronize JIRA project data across departmental and B2B borders with ease, flexibility, and confidence. 
    • JJUPIN - Simple Issue Language (SIL) for JIRA, supported by Kepler-Rominfo
      The JJUPIN plugin provides a new scripting layer for JIRA that enables administrators to create new functionality. It is discussed in the marketplace as being a solution for synchronization and cross-system workflows for federated JIRA environments. 
    • JIRA Enterprise Mail Handlersupported by Javahollic Software
      The JIRA Enterprise Mail Handler is a plugin which was originally designed to provide advanced functionality to handle incoming emails. This includes the interaction with users that do not have a JIRA account or users that use several email aliases. Through its project and field mapping, it can also be used to synchronize and update issues between different instances. For example, you can automatically create an issue in instance A if the issue transitions to a particular state in instance B. Setting up such automation however should be thoroughly tested as there can be occurrences of infinite loop if issues are updated at the same time on both instances.
    • ScriptRunner,  supported by Adaptavist
      ScriptRunner is used by many customers to add further scripting functionality to JIRA. The plugin supports input in languages including Groovy, Python (jython), Ruby (JRuby) and JavaScript. 

フェデレーテッド JIRA システムの REST API を使用する Jelly Scripts を作成し、さらにカスタマイズすることができます。また、これらの機能を提供するカスタム プラグインを開発することもできます。

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

In order to avoid manual repetition of the upgrade instructions given in the JIRA administration manual, there are ways to partially or fully automate the process:

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

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

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

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

JIRA インスタンスのフェデレーションにより、インスタンスに対して異なる可用性要件を設定することができます。例: 一部の JIRA サーバーはフェイルオーバー メカニズムでのみ実現できるアップタイムが必要なバイラル プロセスを実行し、それ以外は全くミッション クリティカルでない場合。複数の JIRA インスタンスにはロードバランサ (HA モードで実行していることを条件とする) など、さまざまなインスタンスに同じツールを活用することもできます。 

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

その他のリソース

JIRA システム間のカスタム同期など、本ガイドで説明されている操作の一部では、スクリプトやシステム管理に関する非常に洗練された知識が必要となります。これら尾実施する際には専門家と協力することをお勧めします。

正しいパートナー / 専門家とつながれるようお手伝いさせていただきます。紹介を必要とされる場合は、ご連絡ください

JIRA のフェデレーションに関するベスト プラクティス、質問、およびコメントを Atlassian Answers にお寄せください。

最終更新日 2018 年 11 月 16 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.