Jira 用にテスト環境を作成する
Jira をアップグレードする際は、本番サイトをアップグレードする前にテスト環境でアップグレードを実施することを強くおすすめします。
The suggested license to apply to a non-production environment is a Developer License, not an Evaluation license. You should only use an Evaluation license if you don't have a Developer license tied to your main license. Check out Get a free license to use in testing environment for details.
環境の複製
テスト環境には、リバース プロキシ、SSL 設定、またはロード バランサ (データ センターの場合) を含めた、実環境 (本番) 環境の複製を用意する必要があります。異なる物理サーバーまたは仮想ソリューションを使用することもできますが、本番環境の適切なレプリカとなるようにします。
以下の説明は、テスト環境が本番環境と物理的に分離されており、同じオペレーティング システムを備えていることを前提としています (Jira を手動でインストールした場合、同一の Java バージョンであることも前提となります)。
テスト環境の作成
1. データベースの複製
データベースを複製する手順
- 本番環境データベースをバックアップします。バックアップの最良の方法の詳細については、データベースのドキュメントを参照してください。
- テスト サーバーにデータベースをインストールし、バックアップを復元します。
データベース バックアップのリストア手順は、選択したデータベースとバックアップ ツールによって異なります。以下を確認してください。
- 新しいテスト データベースが本番環境データベースと異なる名前であること。
- テスト データベースのユーザー アカウントが、本番データベースのユーザー アカウントと同じユーザー名およびパスワードを保持していること。
- 文字エンコードおよびその他の設定は本番データベースと同じです (たとえば、Oracle データベースの場合、文字エンコードは Unicode UTF-8 (または AL32UTF8 のはずです)。
PostgreSQL データベースをご利用の場合は、レプリケーションによってデータやインデックスが断片化する可能性があることにご注意ください。断片化によって、特にインデックス再構築の操作中に環境が低速化する可能性があります。
環境のパフォーマンスを向上させるには、データベースのレプリケート後に次のデータベース メンテナンス コマンドまたはタスクを実行する必要があります。
VACUUM - 古いデータによって使用されているストレージ スペースを再利用します。ANALYZE コマンドも併用できます。Jira のデータベースに対して新しいクエリ プランが作成されて、クエリが最も適切なインデックスを使用するように最適化されます。
REINDEX - インデックスのテーブルのデータによってインデックスを再構築します。インデックスの古いコピーが置き換えられます。
コマンドの詳細については「VACUUM、ANALYZE、REINDEX で PostgreSQL パフォーマンスを最適化して改善する」をご参照ください。
クラスタ
2. Remove production/abandoned nodes from the clusternode
table
これは、本番ノードとテスト ノードが 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 を起動し、テスト サイトが通知やメールを送受信しないことを確認します。メールの無効化の詳細については、「メール送信 / 受信の無効化」を参照してください。
-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 の管理方法をご参照ください。
クラスタ
10. (オプション) 外部ユーザー管理の複製
Crowd または外部ディレクトリでユーザーを管理している場合は、次を実行できます。
- テスト環境の Crowd または外部ディレクトリを複製し、Jira テスト サイトがテスト外部ディレクトリを使用するように指定します (推奨)。
- テスト サーバーに、ネットワーク接続か、本番用サーバーと同じホストへのローカル アクセスを提供します。
11. アプリケーション リンクの変更
Jira と他のアトラシアン アプリケーションの間にアプリケーション リンクが存在し、それらを削除していない場合 (ステップ 5 を参照)、各テスト アプリケーションのサーバー ID を変更します。「Confluence のサーバー ID を変更する方法」および、Jira については「テスト インストールのサーバー ID の変更 」を参照してください。
サーバー ID を変更せずにアプリケーション リンクを更新する場合、本番環境で新しいアプリケーション リンクを作成するとテスト サーバーを参照する可能性があります。
12. (オプション) ルック アンド フィールの変更
テスト インスタンスのルック アンド フィールを変更し、本番環境と異なるロゴや配色を使用することをおすすめします。これにより、ユーザーが、URL のみに依存せずに 2 つの環境を区別するのに役立ちます。
「Jira アプリケーションのルック アンド フィール設定」を参照してください。
おつかれさまでした
ランディング ページに戻り、アップグレード前の手順を完了させましょう