Jira 用にテスト環境を作成する
Jira をアップグレードする際は、本番サイトをアップグレードする前にテスト環境でアップグレードを実施することを強くおすすめします。
非本番環境に適用するライセンスとして推奨されるのは、トライアル ライセンスではなく開発者ライセンスです。トライアル ライセンスは、メインのライセンスに紐付いた開発者ライセンスを持っていない場合にのみ使用することをおすすめします。Jira Data Center トライアル ライセンスを入手する方法とライセンスの互換性についての詳細をご確認ください。
環境の複製
テスト環境には、リバース プロキシ、SSL 設定、またはロード バランサー (Data Center の場合) を含めた、実環境 (本番環境) の複製を用意する必要があります。異なる物理サーバーまたは仮想ソリューションを使用することもできますが、本番環境の適切な複製となるようにしてください。
CDNのURL
レプリカを含む各環境には、独自のコンテンツ配信ネットワーク (CDN) URL が必要です。エラーを防ぐため、環境を複製したら次のいずれかを実行できます。
- 下位環境で CDN を無効にする
- 下位インスタンスの CDN URL を本番環境とは異なるものに変更する
以下の説明は、テスト環境が本番環境と物理的に分離されており、同じオペレーティング システムを備えていることを前提としています (Jira を手動でインストールした場合には、同一の Java バージョンであることも前提となります)。
テスト環境の作成
1. データベースの複製
データベースを複製する手順
- 本番環境データベースをバックアップします。バックアップの最良の方法の詳細については、データベースのドキュメントを参照してください。
- テスト サーバーにデータベースをインストールし、バックアップを復元します。
データベース バックアップのリストア手順は、選択したデータベースとバックアップ ツールによって異なります。以下を確認してください。
- 新しいテスト データベースが本番環境データベースと異なる名前であること。
- テスト データベースのユーザー アカウントが、本番データベースのユーザー アカウントと同じユーザー名およびパスワードを保持していること。
- 文字エンコードおよびその他の設定は本番データベースと同じです (たとえば、Oracle データベースの場合、文字エンコードは Unicode UTF-8 (または AL32UTF8 のはずです)。
クラスタ
2. clusternode
テーブルから本番環境/不要なノードを削除する
データベースを更新した後、Jira のバックアップを開始する前に、本番環境ノードをステージから削除して、本番環境ノードとテスト ノードが 1 つのクラスタのように動作しないようにします。これを行う方法は次のとおりです。
clusternode
テーブルのコンテンツを確認します。このテーブルは、Jira が Data Center のオペレーションで使用するリファレンスです。次のコマンドを実行します。SELECT * FROM clusternode;
本番環境ノードのすべてのレコードを削除します。
不要になったノードのレコードは、あとでインデックスの再作成操作に影響を与える可能性があるため、削除します。方法については、この記事を参照してください。
バックアップでも、不要になったノードが
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';
5. (オプション) アプリケーション リンクの削除
Jira と他のアトラシアン アプリケーションの間のアプリケーション リンクを削除し、本番環境とテスト環境のリンクを混同しないようにします。リンクを保持して更新することもできますが (ステップ 11 を参照) できますが、まとめて削除するほうが問題が少なく済みます。詳細については、「SQL を使用して Jira サーバーからアプリケーション リンクを削除する」を参照してください。
6. Jira の複製
Jira を複製するには、Jira インストールのコピーを作成し、それがテスト データベースをポイントするようにします。
- 本番環境のインストール ディレクトリ全体をテスト サーバーにコピーします。
- 本番環境のホーム ディレクトリ全体をテスト サーバーにコピーします。
<installation-directory>/atlassian-jira/WEB-INF/classes/jira-application.properties
を編集し、テスト ホーム ディレクトリをポイントするようにします。
クラスタ Data Center の場合、すべてのノードでこの変更を実行します。<home-directory>/dbconfig.xml
または<installation-directory>/server.xml
(以前のバージョン) を編集し、テスト データベースをポイントするようにします。テスト環境が本番環境のデータベースを参照していないことを確認します。
クラスタ
7. 共有ホーム ディレクトリの管理
- 本番環境の共有ホーム ディレクトリをテスト サーバーにコピーします。
<local-home-directory>/cluster.properties
を編集し、テスト環境の共有ホーム ディレクトリをポイントするようにします。すべてのテスト ノードでこの変更を実行します。
8. テスト環境で Jira を起動
テスト環境で Jira を起動する前に、次のことをご確認ください。
ehcache.listener.hostName
の IP 値をテスト サーバーの IP アドレスに更新しています。該当しない場合は、インスタンスが起動しない可能性があります。- 本番環境インスタンスとテスト インスタンスは、ポート 40001 とポート 40011 を介して通信できません。
以下のシステム プロパティで Jira を起動し、テスト サイトが通知やメールを送受信しないことを確認します。メールの無効化の詳細については、「メール送信 / 受信の無効化」を参照してください。
-Datlassian.notifications.disabled=true -Datlassian.mail.senddisabled=true -Datlassian.mail.fetchdisabled=true -Datlassian.mail.popdisabled=true
クラスタ ノードを 1 つずつ起動します。
http://localhost:<port>
に進み、テスト サーバーの Jira にログインします。- [管理 ()] > [システム] > [一般設定] の順に移動して、テスト サイトのベース URL を変更します (例:
mysite.test.com
)。 - [管理 ()] > [アプリ] > [バージョンとライセンス] の順に移動して、開発ライセンスを適用します。ライセンスを更新するには、その横にある編集アイコンをクリックします。
[管理] () > [システム] > [システム情報] に進み、Jira がテスト データベースおよびテスト ホーム ディレクトリを正しくポイントしていることを確認します。
[管理 ()] > [システム] > [ルック アンド フィール] の順に移動して、テスト インスタンスの色を本番環境インスタンスと異なる色に変更します。これは小さな変更ですが、大きなミスの防止に役立つ可能性があります。
9. Webhook を更新する
テスト環境では本番環境の Webhook をトリガーできません。そのため、本番環境の Webhook を新しい環境で編集してから、無効にするか、テストの Webhook に変更する必要があります。
Webhook を管理する方法をご覧ください。ドキュメントには、Jira Service Management 自動化 Webhook が更新されていることを確認する方法も記載されています。
クラスタ
10. (オプション) 外部ユーザー管理の複製
Crowd または外部ディレクトリでユーザーを管理している場合は、次を実行できます。
- テスト環境の Crowd または外部ディレクトリを複製し、Jira テスト サイトがテスト外部ディレクトリを使用するように指定します (推奨)。
- テスト サーバーに、ネットワーク接続か、本番用サーバーと同じホストへのローカル アクセスを提供します。
11. アプリケーション リンクの変更
Jira と他のアトラシアン アプリケーションの間にアプリケーション リンクが存在し、それらを削除していない場合 (ステップ 5 を参照)、各テスト アプリケーションのサーバー ID を変更します。「Confluence のサーバー ID を変更する方法」および、Jira については「テスト インストールのサーバー ID の変更 」を参照してください。
サーバー ID を変更せずにアプリケーション リンクを更新する場合、本番環境で新しいアプリケーション リンクを作成するとテスト サーバーを参照する可能性があります。
12. Jira のインデックスを再構築する
本番環境の Jira インデックスはテスト環境のインデックスと互換性がなくなるため、Jira のインデックスを再作成する必要があります。課題とアプリの数に応じて、インデックスの再作成には時間がかかる可能性があります。
- [管理] > [システム] の順に移動します。
- 左側のパネルで [インデックス化] を選択します。
- [オプション] で [完全再インデックス] を選択します。
- [再インデックス化] ボタンを選択します。
13. (オプション) ルック アンド フィールの変更
テスト インスタンスのルック アンド フィールを変更し、本番環境と異なるロゴや配色を使用することをおすすめします。これにより、ユーザーが、URL のみに依存せずに 2 つの環境を区別するのに役立ちます。
「Jira アプリケーションのルック アンド フィール設定」を参照してください。
おつかれさまでした
ランディング ページに戻り、アップグレード前の手順を完了させましょう