アップグレード チェックリスト

Jira Software アップグレードのセットアップを成功させるために、このチェックリストをガイドとしてご利用ください。すべてのインスタンスはそれぞれ異なることにご注意ください。このガイドは、インスタンスに固有のタスクやカスタマイズを補完するためのものです。

このテンプレートを使用し、お使いの Jira Software インスタンスに合わせて追記することをおすすめします。

チェックリストを Trello ボードで確認 

段階タスク注意

ステータス / コメント

調査と決定

アップグレード後のバージョンを決定する

  • Jira Software アップグレード マトリクスを使用してバージョンを比較し、ニーズに最適なバージョンを選択します。次に、アップグレード ノートでアップグレードの技術的な側面を確認します。

    tip/resting Sketch で作成されました。 ヒント: 頻繁にアップグレードしない場合は、長期サポートの最新リリースをご検討ください。

アップグレードのステークホルダーを大まかに決定する (任意)
  • 役割、責任範囲、および連絡先を一覧化して、関係者と常に情報を共有し、すべての依存関係を把握できるようにします。

準備とテスト


メンテナンス ステータスを確認する
  • You need to have a valid licence to upgrade Jira. Check and renew at my.atlassian.com.

カスタム変更を含むファイルの一覧を取得

Jira をカスタマイズするためにファイルを変更した場合、その変更を保持するには、どのファイルを変更したかを把握する必要があります。 

  • ASTS プラグインの最新バージョンをご利用の場合は、[Jira 管理] > [アプリ] > [アップグレードを計画] の順に選択して、カスタム変更を行ったファイルのリストを表示します。

     次を変更した場合 

    - <jira-home-directory>/atlassian-jira/ directory
    - <jira-home-directory>/conf/server.xml
    - <jira-home-directory>/bin/setenv.sh

    これらの変更はアップグレードされた Jira を開始する前に自動転送されます。ただし、その他のファイルを変更した場合、手動で転送する必要があります。

詳細については、「アップグレード前のプランニング ツール」をご覧ください。



サポート対象プラットフォームを確認する
テスト環境のセットアップ
インスタンス ヘルス チェックの実行
  • インスタンスがアップグレード可能かどうかを確認します。ヘルス チェックは Support Tools Plugin に含まれています。詳細はこちら

アプリの互換性の確認
  1. Jira の更新チェックでアプリの互換性を確認します。
  2. Jira 8.0 では大規模な変更が加えられたため、アップグレードの前に、互換性のないアプリをすべて無効化する必要があります。また、次のステータスのアプリも無効化することをお勧めします。
    • Incompatible
    • Compatible if both upgraded
    • Unknown
  3. "Compatible if upgraded" ステータスのアプリをアップグレードします。

    互換性のないアプリ」を参照してください。

最適なアップグレード方法を決定する

Jira のアップグレード方法を選択します。

Jira 6.4 以前をご利用の場合は、8.x にアップグレードする前に Jira 7.x (例: 7.13) にアップグレードする必要があります。

tip/resting Sketch で作成されました。 ヒント: お使いの OS や、Data Center をクラスタ化しているかどうかによって、選択できるアップグレード方法に制約が生じる場合があります。「アップグレード方法」をご参照ください。

アップグレードの実行

クラスタ アップグレードを行う際は、アップグレード前の手順をすべて実行し、1 つのノードでアップグレードを実行してアップグレード後の手順を実行します。次にテンプレートを作成し、他のすべてのノードをアップグレードします。これが完了するまでは、DC 全体でアップグレード後の手順を実行することはできません。


任意の変更を再適用して pool-max-size を増やす
いずれかのファイルに変更を加えた場合は、アップグレードしたインスタンスにそれらをコピーします。変更には次のようなものがあります。
  • xml 構成ファイルへのカスタマイズ (例: ロード バランシングの使用を可能にする)

  • カスタム アイコン (例: Jira ロゴを会社ロゴで置き換える)

  • カスタム メール テンプレート (ブランディングと同様)

アップグレード中の変更によって Jira Software のカスタマイズが使用できなくなる可能性があるため、本番インスタンスでアップグレードを実施する前にステージング環境でカスタマイズのテストを実施することを強く推奨します。

変更されたファイルはどれですか?

どのファイルを変更したか分からない場合は、[Jira 管理] > [アプリ] > [アップグレードを計画] の順に移動して、カスタム変更を導入したファイルのリストを確認します。

または、Jira インストール ディレクトリの重要なファイルの一覧をご確認ください。変更セクションで履歴を確認することもできます。

インストーラーを使用している場合、既存の Jira Software インストールから次のパラメーターが移行されます。

  • server.xml ファイルの TCP の値。
  • Jira-application.properties ファイルに記載された Jira ホーム ディレクトリの場所。
  • setenv.sh / setenv.bat ファイルの次の値:
    • JVM_SUPPORT_RECOMMENDED_ARGS
    • JVM_MINIMUM_MEMORY
    • JVM_MAXIMUM_MEMORY
    • Jira_MAX_PERM_SIZE
変更したファイルをどうするべきですか?

どのファイルが編集されたかを確認できている場合、それらの変更をアップグレード後の Jira の各ファイルにコピーします。ファイル全体ではなく、変更された部分のみをコピーするようにします。

Jira 8.6 以降にアップグレードしようとしていて、ATST バージョン 1.20.0 以降を実行している場合、Jira の起動時に、変更がコピーされなかったファイルが表示されます。この場合、変更を自動的にコピーできます。

コピーの完了後に Jira を再起動するよう求められます。

Jira 7.x を Jira 8.x にアップグレードする場合は、アップグレードの前に dbconfig.xml で pool-max-size パラメーターを 40 に変更することをおすすめします。デフォルトの 20 のままにしておくと、8.x でインデックスの再作成を実行する際に “ResultSet Closed” エラーが発生することがあります。変更の実装の詳細については「データベース接続のチューニング」を参照してください。

dbconfig.xml に変更を加えた場合は、再起動が必要です。


再インデックスのタイミングの決定

7.x から 8.x へのアップグレード Jira は起動時に、互換性のない古いインデックスを自動的に削除し、完全な再インデックスを開始します。一部のアプリでは追加の再インデックスが必要になるため、アプリをアップグレードするまで再インデックスを延期することもできます。詳細は、「自動的な再インデックスの無効化」を参照してください。


Jira の起動

アプリのアップグレードこれで、"Compatible if both upgraded" ステータスのアプリをアップグレードできます。
変更の再適用 (まだ実行していない場合)

Jira 8.6 以降にアップグレードしていて ATST バージョン 1.20.0 以降を実行している場合は、Jira の起動時に変更がコピーされなかったファイルのリストが表示されます。その後、選択すると変更が自動でコピーされます。

変更を確認する際は、次のファイル / フォルダのみが確認される点にご注意ください。

- <jira-home-directory>/atlassian-jira/ directory
- <jira-home-directory>/conf/server.xml
- <jira-home-directory>/bin/setenv.sh

変更を自動的に転送するには、変更されたファイルのインストーラーのコピーがアップグレード後のバージョンと同じである必要があります。

コピーの完了後に Jira を再起動するよう求められます。


ユーザーによるアップグレード テスト
  • Jira ユーザーに対して、アップグレード後に Jira を正常に利用できているかどうかを確認します。これは、メジャー バージョン (例: 8.0) にアップグレードする場合に大変便利です。Jira Software の異なる機能を活用するさまざまなサンプル グループを選択しましょう。

確認事項の記録 (任意)
  • アップグレード中に気付いた点を文書化します。これは将来のアップグレードに役立ちます。
  • 必要に応じてタイムラインとステークホルダーを更新します。

タイムラインの作成とコミュニケーション
  • アップグレードに十分な時間を確保するようにします。ある程度の猶予時間も必要です。
  • 変更をエンドユーザーに通知します。

準備と実施



メンテナンス ステータスを確認する
  • You need to have a valid licence to upgrade Jira. Check and renew at my.atlassian.com.

サポート対象プラットフォームを確認する
インスタンス ヘルス チェックの実行
  • インスタンスがアップグレード可能かどうかを確認します。ヘルス チェックは Support Tools Plugin に含まれています。詳細はこちら

アプリの互換性の確認
  1. Jira の更新チェックでアプリの互換性を確認します。
  2. 7.x から 8.x へのアップグレード Jira 8.0 では大規模な変更が加えられたため、アップグレードの前に、互換性のないアプリをすべて無効化する必要があります。また、次のステータスのアプリも無効化することをお勧めします。
    • Incompatible
    • Compatible if both upgraded
    • Unknown
  3. "Compatible if upgraded" ステータスのアプリをアップグレードします。

    互換性のないアプリ」を参照してください。

インスタンス データのバックアップ
  • ネイティブのデータベース バックアップ ツールを使用します。ただし、環境の一部 (例: データベース ソフトウェア) を変更した場合は、Jira の XML バックアップ ユーティリティを使用する必要があります。
  • 2 つのプロセスの詳細な内容については、こちらをご確認ください。 

ディレクトリのバックアップ
  • インストール ディレクトリとホーム ディレクトリのバックアップを作成します。詳細についてはこちらをご参照ください。
    クラスタ すべてのノードでバックアップを実行し、共有ディレクトリのバックアップも作成します。

7.x から 8.x へのアップグレード 再インデックスのタイミングの決定

Jira 8.0 は互換性のない古いインデックスを自動的に削除し、起動時に完全な再インデックスを開始します。一部のアプリでは追加の再インデックスが必要になるため、アプリをアップグレードするまで再インデックスを延期することもできます。詳細については、「自動的な再インデックスの無効化」をご確認ください。


本番環境でのアップグレードの実行

次のアップグレード方法を使用できます。

Jira 6.4 以前をご利用の場合は、8.x にアップグレードする前に Jira 7.x にアップグレードする必要があります。

tip/resting Sketch で作成されました。 ヒント: お使いの OS や、Data Center をクラスタ化しているかどうかによって、選択できるアップグレード方法に制約が生じる場合があります。「アップグレード方法」をご参照ください。

クラスタ アップグレードを行う際は、アップグレード前の手順をすべて実行し、1 つのノードでアップグレードを実行してアップグレード後の手順を実行します。次にテンプレートを作成し、他のすべてのノードをアップグレードします。これが完了するまでは、DC 全体でアップグレード後の手順を実行することはできません。


データベース ドライバーのアップグレード (Oracle または MySQL を使用している場合)

Jira を正常に起動するには、次の手順を実行します。

  • 最新の JDBC ドライバ (Oracle または MySQL) をダウンロードします。
  • <Jira-installation-directory>/lib に配置します。

変更の再適用
ファイルに変更を加えた場合、アップグレードしたインスタンスにそれらをコピーします。変更には次のようなものがあります。
  • xml 構成ファイルへのカスタマイズ (例: ロード バランシングの使用を可能にする)

  • カスタム アイコン (例: Jira ロゴを会社ロゴで置き換える)

  • カスタム メール テンプレート (ブランディングと同様)

変更されたファイルはどれですか?

どのファイルを変更したか分からない場合は、[Jira 管理] > [アプリ] > [アップグレードを計画] の順に移動して、カスタム変更を導入したファイルのリストを確認します。

または、Jira インストール ディレクトリの重要なファイルの一覧をご確認ください。変更セクションで履歴を確認することもできます。

インストーラーを使用している場合、既存の Jira Software インストールから次のパラメーターが移行されます。

  • server.xml ファイルの TCP の値。
  • Jira-application.properties ファイルに記載された Jira ホーム ディレクトリの場所。
  • setenv.sh / setenv.bat ファイルの次の値:
    • JVM_SUPPORT_RECOMMENDED_ARGS
    • JVM_MINIMUM_MEMORY
    • JVM_MAXIMUM_MEMORY
    • Jira_MAX_PERM_SIZE
変更したファイルをどうするべきですか?

どのファイルが編集されたかを確認できている場合、それらの変更をアップグレード後の Jira の各ファイルにコピーします。ファイル全体ではなく、変更された部分のみをコピーするようにします。

Jira 8.6 以降にアップグレードしようとしていて、ATST バージョン 1.20.0 以降を実行している場合、Jira の起動時に、変更がコピーされなかったファイルが表示されます。この場合、変更を自動的にコピーできます。

コピーの完了後に Jira を再起動するよう求められます。


7.x から 8.x へのアップグレード 再インデックスのタイミングの決定

Jira 8.0 は互換性のない古いインデックスを自動的に削除し、起動時に完全な再インデックスを開始します。一部のアプリでは追加の再インデックスが必要になるため、アプリをアップグレードするまで再インデックスを延期することもできます。詳細は、「自動的な再インデックスの無効化」を参照してください。
Jira の起動

アプリのアップグレードこれで、"Compatible if both upgraded" ステータスのアプリをアップグレードできます。
変更の再適用 (まだ実行していない場合)

Jira 8.6 以降にアップグレードしていて ATST バージョン 1.20.0 以降を実行している場合は、Jira の起動時に変更がコピーされなかったファイルのリストが表示されます。その後、選択すると変更が自動でコピーされます。

変更を確認する際は、次のファイル / フォルダのみが確認される点にご注意ください。

- <jira-home-directory>/atlassian-jira/ directory
- <jira-home-directory>/conf/server.xml
- <jira-home-directory>/bin/setenv.sh

変更を自動的に転送するには、変更されたファイルのインストーラーのコピーがアップグレード後のバージョンと同じである必要があります。

コピーの完了後に Jira を再起動するよう求められます。


アップグレード後ユーザーによるアップグレード テスト
  • アップグレード後に Jira を正常に利用できているかどうかをユーザーに確認します。
  • テスト アップグレードと同じサンプル グループを使用します。
  • アップグレードを完了する前に課題を解決します。

エンドユーザーへの通知

主要な機能追加や、問い合わせ用の連絡先情報を含めます。


アップグレードのふりかえり (任意)

想定どおりに進んだ点、進まなかった点、次回に変更すべき点を文書化します。この作業は、次回のアップグレードをさらにスムーズに実行するために役立ちます。



リソース

問題が発生した場合、次のリソースを利用できます。記載順で確認することをおすすめします。 

  • Jira Software ドキュメンテーション サイトと Jira Software Data Center ナレッジ ベースを参照または検索します (ドロップダウンで正しいバージョンを選択するようにしてください)。
  • アトラシアン コミュニティ サイト で、トピックに関する記事やディスカッションを検索します。または、アトラシアン内外のコミュニティ エキスパートに質問します。 
  • サポート エンジニアがサポートできるようサポート サイトで課題を作成します。
  • 認定ソリューション パートナーを通じてライセンスを購入した場合は、インスタンスのトラブルシューティングについてのパートナーに問い合わせてください。
  • さらにサポートが必要な場合、24 時間/週 7 日のサポート、ヘルス チェック、専任のシニア サポート エンジニアが含まれるプレミアム サポートも提供しています。詳細は、「プレミアム サポートについて」をご覧ください。


おつかれさまでした

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

最終更新日: 2023 年 12 月 1 日

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

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