Jira 用にテスト環境を作成する

Jira をアップグレードする際は、本番サイトをアップグレードする前にテスト環境でアップグレードを実施することを強くおすすめします。

非本番環境に適用するライセンスとして推奨されるのは、評価ライセンスではなく開発者ライセンスです。評価ライセンスは、メインのライセンスに紐付いた開発者ライセンスを持っていない場合にのみ使用することをおすすめします。詳細とライセンスの互換性はJira Data Center トライアル ライセンスを入手する」をご確認ください。

環境の複製

テスト環境には、リバース プロキシ、SSL 設定、またはロード バランサ (データ センターの場合) を含めた、実環境 (本番) 環境の複製を用意する必要があります。異なる物理サーバーまたは仮想ソリューションを使用することもできますが、本番環境の適切なレプリカとなるようにします。 

CDNのURL

レプリカを含む各環境には、独自のコンテンツ配信ネットワーク (CDN) URL が必要です。エラーを防ぐため、環境を複製したら次のいずれかを実行できます。

  • 下位環境で CDN を無効にする
  • 下位インスタンスの CDN URL を本番環境とは異なるものに変更する

Jira 用に CDN を構成する方法をご確認ください。

以下の説明は、テスト環境が本番環境と物理的に分離されており、同じオペレーティング システムを備えていることを前提としています (Jira を手動でインストールした場合には、同一の Java バージョンであることも前提となります)。 

テスト環境の作成

1. データベースの複製

データベースを複製する手順

  1. 本番環境データベースをバックアップします。バックアップの最良の方法の詳細については、データベースのドキュメントを参照してください。 
  2. テスト サーバーにデータベースをインストールし、バックアップを復元します。 

データベース バックアップのリストア手順は、選択したデータベースとバックアップ ツールによって異なります。以下を確認してください。

  • 新しいテスト データベースが本番環境データベースと異なる名前であること。
  • テスト データベースのユーザー アカウントが、本番データベースのユーザー アカウントと同じユーザー名およびパスワードを保持していること。
  • 文字エンコードおよびその他の設定は本番データベースと同じです (たとえば、Oracle データベースの場合、文字エンコードは Unicode UTF-8 (または AL32UTF8 のはずです)。

PostgreSQL データベース複製に関する課題

PostgreSQL データベースをご利用の場合は、レプリケーションによってデータやインデックスが断片化する可能性があることにご注意ください。断片化によって、特にインデックス再構築の操作中に環境が低速化する可能性があります。

環境のパフォーマンスを向上させるには、データベースのレプリケート後に次のデータベース メンテナンス コマンドまたはタスクを実行する必要があります

  1. VACUUM - 古いデータによって使用されているストレージ スペースを再利用します。ANALYZE コマンドも併用できます。Jira のデータベースに対して新しいクエリ プランが作成されて、クエリが最も適切なインデックスを使用するように最適化されます。

  2. REINDEX - インデックスのテーブルのデータによってインデックスを再構築します。インデックスの古いコピーが置き換えられます。

コマンドの詳細については「VACUUM、ANALYZE、REINDEX で PostgreSQL パフォーマンスを最適化して改善する」をご参照ください。

Microsoft Teams for Jira を使用している場合に OAuth と Jira ID を削除する理由

Microsoft Teams for Jira を使用している場合、MS Teams 統合から OAuth キーと Jira ID を手動で削除する必要があります。

統合データはデータベースに保存され、アプリまたはアプリケーション リンクを削除しても消去されません。そのため、このデータを手動で削除しなければ、MS Teams for Jira の設定ページに、本番インスタンスの OAuth キーと Jira ID が保持されます。

OAuth キーと Jira ID を削除するには、このナレッジ ベースの記事の手順に従います。

クラスタ

2. clusternode テーブルから本番環境/不要なノードを削除する

データベースを更新した後、Jira のバックアップを開始する前に、本番環境ノードをステージから削除して、本番環境ノードとテスト ノードが 1 つのクラスタのように動作しないようにします。これを行う方法は次のとおりです。

  1. clusternode テーブルのコンテンツを確認します。このテーブルは、Jira が Data Center のオペレーションで使用するリファレンスです。次のコマンドを実行します。

    SELECT * FROM clusternode;
  2. 本番環境ノードのすべてのレコードを削除します。

  3. 不要になったノードのレコードは、あとでインデックスの再作成操作に影響を与える可能性があるため、削除します。方法については、この記事を参照してください。

    バックアップでも、不要になったノードが clusternode テーブルに取り込まれます。

さらに、本番環境とテスト環境が別のサブネット内にあることを確認します。これは、テスト環境で本番環境との通信を試みるのを防ぐためです。ネットワーク内でクラスタ同士が互いを確認できる場合、問題が発生する可能性があります。

3. テキスト ガジェットで本番環境 URL を更新する

テキスト ガジェットを使用すると、カスタムの html テキストをダッシュボードに表示できます。

URL を更新しない場合、テスト環境のダッシュボードのリンクは本番環境へのリダイレクトを行い、その結果、ユーザーにはエラー ページが表示されます。
古い URL を新しい URL に置き換えます。たとえば ProgreSQL の場合は次のコマンドを使用します。

update gadgetuserpreference set userprefvalue = REPLACE(userprefvalue, '//prod.jira.base.url/', '//test.jira.base.url/') where userprefvalue like '%//prod.jira.base.url/%';

MSSQL の場合:

update gadgetuserpreference set userprefvalue = cast(replace(cast(userprefvalue as nvarchar(max)),'//prod.jira.base.url/','//test.jira.base.url/') as text) where userprefvalue like '%//prod.jira.base.url/%';


Remember to replace the production and test.jira.base.url in the command with your production and test Jira base URLs. For example, jira.atlassian.com and jira-test.atlassian.com.

4. メール サーバーのデータを削除する

テスト環境からメールが送信され、本番環境でなくテスト環境で課題が作成されることを防ぐため、 mailserver テーブルのデータを削除して、すべての受信および送信メール サーバーを削除します。

さらに、次のコマンドを実行して、すべてのメール ハンドラーを削除します。

delete from serviceconfig where clazz='com.atlassian.jira.service.services.mail.MailFetcherService'

テスト環境からメールが送信されないように、次の操作を行うこともおすすめします。

  • 次のコマンドで、Jira データベースのすべてのサブスクリプションを削除します。
delete from filtersubscription;
  • Jira データベースですべてのプロジェクトから通知スキームを削除するには、次のコマンドを実行します。
delete from nodeassociation where sink_node_entity='NotificationScheme

Jira と他のアトラシアン アプリケーションの間のアプリケーション リンクを削除し、本番環境とテスト環境のリンクを混同しないようにします。リンクを保持して更新することもできますが (ステップ 11 を参照) できますが、まとめて削除するほうが問題が少なく済みます。詳細については、「SQL を使用して Jira サーバーからアプリケーション リンクを削除する」を参照してください。

6. Jira の複製

Jira を複製するには、Jira インストールのコピーを作成し、それがテスト データベースをポイントするようにします。

  1. 本番環境のインストール ディレクトリ全体をテスト サーバーにコピーします。 
  2. 本番環境のホーム ディレクトリ全体をテスト サーバーにコピーします。 
  3. <installation-directory>/atlassian-jira/WEB-INF/classes/jira-application.properties を編集し、テスト ホーム ディレクトリをポイントするようにします。
    クラスタ Data Center の場合、すべてのノードでこの変更を実行します。
  4. <home-directory>/dbconfig.xmlまたは  <installation-directory>/server.xml (以前のバージョン) を編集し、テスト データベースをポイントするようにします。 

    テスト環境が本番環境のデータベースを参照していないことを確認します。

クラスタ

7. 共有ホーム ディレクトリの管理

  1. 本番環境の共有ホーム ディレクトリをテスト サーバーにコピーします。 
  2. <local-home-directory>/cluster.properties を編集し、テスト環境の共有ホーム ディレクトリをポイントするようにします。すべてのテスト ノードでこの変更を実行します。 

8. テスト環境で Jira を起動

テスト環境で Jira を起動する前に、次のことをご確認ください。

  • ehcache.listener.hostName の IP 値をテスト サーバーの IP アドレスに更新しています。該当しない場合は、インスタンスが起動しない可能性があります。
  • 本番環境インスタンスとテスト インスタンスは、ポート 40001 とポート 40011 を介して通信できません
  1. 以下のシステム プロパティで Jira を起動し、テスト サイトが通知やメールを送受信しないことを確認します。メールの無効化の詳細については、「メール送信 / 受信の無効化」を参照してください。   

    -Datlassian.notifications.disabled=true
    -Datlassian.mail.senddisabled=true
    -Datlassian.mail.fetchdisabled=true
    -Datlassian.mail.popdisabled=true

    クラスタ ノードを 1 つずつ起動します。

    テスト メール通知が必要な場合
    その場合、メール通知を有効にしたまま、環境サーバーのメール設定を準備できます。
  2.  http://localhost:<port>  に進み、テスト サーバーの Jira にログインします。 
  3. [管理 ()] > [システム] > [一般設定] の順に移動して、テスト サイトのベース URL を変更します (例:  mysite.test.com )。
  4. [管理 ()] > [アプリ] > [バージョンとライセンス] の順に移動して、開発ライセンスを適用します。ライセンスを更新するには、その横にある編集アイコンをクリックします。
  5. [管理] () > [システム] > [システム情報] に進み、Jira がテスト データベースおよびテスト ホーム ディレクトリを正しくポイントしていることを確認します。 

  6. [管理 ()] > [システム] > [ルック アンド フィール] の順に移動して、テスト インスタンスの色を本番環境インスタンスと異なる色に変更します。これは小さな変更ですが、大きなミスの防止に役立つ可能性があります。

9. Webhook を更新する

テスト環境では本番環境の Webhook をトリガーできません。そのため、本番環境の Webhook を新しい環境で編集してから、無効にするか、テストの Webhook に変更する必要があります。

Webhook を管理する方法をご覧ください。ドキュメントには、Jira Service Management 自動化 Webhook が更新されていることを確認する方法も記載されています。

クラスタ

10. (オプション) 外部ユーザー管理の複製

Crowd または外部ディレクトリでユーザーを管理している場合は、次を実行できます。

  • テスト環境の Crowd または外部ディレクトリを複製し、Jira テスト サイトがテスト外部ディレクトリを使用するように指定します (推奨)。
  • テスト サーバーに、ネットワーク接続か、本番用サーバーと同じホストへのローカル アクセスを提供します。 

Jira と他のアトラシアン アプリケーションの間にアプリケーション リンクが存在し、それらを削除していない場合 (ステップ 5 を参照)、各テスト アプリケーションのサーバー ID を変更します。「Confluence のサーバー ID を変更する方法」および、Jira については「テスト インストールのサーバー ID の変更 」を参照してください。 

サーバー ID を変更せずにアプリケーション リンクを更新する場合、本番環境で新しいアプリケーション リンクを作成するとテスト サーバーを参照する可能性があります。

12. Jira のインデックスを再構築する

本番環境の Jira インデックスはテスト環境のインデックスと互換性がなくなるため、Jira のインデックスを再作成する必要があります。課題とアプリの数に応じて、インデックスの再作成には時間がかかる可能性があります。

  1. [管理] > [システム] の順に移動します。
  2. 左側のパネルで [インデックス化] を選択します。
  3. [オプション] で [完全再インデックス] を選択します。
  4. [再インデックス化] ボタンを選択します。

13. (オプション) ルック アンド フィールの変更

テスト インスタンスのルック アンド フィールを変更し、本番環境と異なるロゴや配色を使用することをおすすめします。これにより、ユーザーが、URL のみに依存せずに 2 つの環境を区別するのに役立ちます。
Jira アプリケーションのルック アンド フィール設定」を参照してください。

おつかれさまでした

ランディング ページに戻り、アップグレード前の手順を完了させましょう

ランディング ページに移動

最終更新日 2024 年 7 月 4 日

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

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