Jira Software 8.8.x アップグレード ノート

さらに前

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

ここでは、Jira Software 8.8 へのアップグレードに関する重要な注意事項について説明します。

このリリースの新機能と改善の詳細については、「Jira Software 8.8.x リリース ノート」を参照してください。 


 アップグレード ノート

Increase pool-max-size on upgrade

If you're upgrading from Jira 7.x to Jira 8.x we recommend changing the pool-max-size parameter to 40 in your dbconfig.xml before the upgrade. Leaving the default of 20 can sometimes lead to “ResultSet Closed” errors during re-indexing on 8.x. For information on implementing the change, see Tuning database connections.

バージョン ビューの読み込み速度を上げるのに役立つ新しい API

Available from Jira 8.8.1

プロジェクト設定でのバージョン ビューの読み込みを高速化して大規模なインスタンスでのタイムアウトを回避するために、呼び出されたエンドポイントを変更しました。 

Now, instead of .../release/allversions we use GET /rest/projects/1.0/project/<project_key>/release/allversions-nodetails to return the list of all project versions together with their data such as their name, status, or description (except the progress data). Archived versions are also returned. 

また、各バージョンに関連する各ステータス カテゴリ (すること、進行中、完了) の課題の数についての情報を返す方法も変更しました。総称して「進捗」と呼ばれるこのデータは、ページがスクロールされると遅延読み込みされるようになって、別の新しいエンドポイントを使用します。 

The old endpoint is still working however, will not be used by the releases including and following Jira 7.13.14, 8.5.5, 8.8.1 and 8.9. 

New endpoint取得するデータ

GET

/rest/projects/1.0/project/<project_key>/release/allversions-nodetails

プロジェクトのバージョンとそのデータのリスト
POST /rest/projects/1.0/project/<project_key>/release/details/progress各バージョンの進捗状況

This is not a breaking change. 

Fetching updates to be fixed for Jira in version 8.8.2

If you use Jira with other Atlassian products such as Bamboo, Bitbucket or Fisheye/Crucible, you might have experienced it getting stuck paging over issue updates. This happens when the collective number of results to fetch is bigger than 50. We have worked on a fix and will bundle it in Jira version 8.8.2. Make sure you upgrade to this version for Jira to update without further issues.

Java 11 ではデフォルトで G11 GC が有効

Java 11 で Jira を実行している場合、ガベージ ファースト ガベージ コレクション (G1 GC) は既定で有効になります。これまでも、ガベージ コレクションをチューニングする際にはこの方法が推奨されていましたが、今後はすぐ利用できます。特に Java ヒープが大きい環境では、G1 GC はより効率的でパフォーマンスの向上に役立ちます。

Java バージョン既定の GC推奨される GC
Java 11G1 GC
  • 大規模な Java ヒープの G1 GC
  • 小さい Java ヒープの ParallelGC*
Java 8ParallelGCParallelGC

*パフォーマンス テストでは、Java ヒープが比較的小さい場合は ParallelGC の恩恵を受ける可能性があることが示されています。大きな違いはありませんが、パフォーマンスに問題がある場合は ParallelGC に戻すことをご検討ください。

GC メソッドを変更するにはどうすればよいですか?

デフォルトの GC メソッドの変更方法:

  1. Jira を停止します。

  2. setenv.sh/.bat ファイルを編集して、JVM_GC_ARGS を検索します。利用可能なパラメーターはその内部で説明されています。

  3. Windows で Jira をサービスとして実行している場合は、gc-params-service.bat ファイルも変更する必要があります。

サポート対象のすべてのメール ハンドラー

In Jira 8.6 we decided to deprecate two email handlers that do not use regex: ”Add a comment from the non-quoted email body” and ”Create a new issue or add a comment to an existing issue” (see the announcement). We advised users to switch to the handlers which use regular expressions to get rid of unwanted content such as email footers or signatures. 

それ以降、当社は廃止に関する重要なフィードバックをいただいてきました。結果として、メール ハンドラーを元に戻すことにしました。

2 つのメール ハンドラーは廃止せずに代わりに既存のハンドラーに正規表現を追加し、管理者がメールで Jira 課題に追加された不要なコンテンツを管理できるようにします。

新しい API エンドポイント

As a result of introducing the Advanced auditing feature, we've added new REST endpoints. For more information, see here

監査ログの移行

Jira 8.8 に導入される改善した監査ログでは、アップグレード時に既存の監査ログ (最大千万レコード) を移行する必要があります。

既存のイベントは、データベースに移行されます。

移行は Jira 起動時に実行される

移行は、通常のアップグレードでは起動時に、Data Center の ZDU アップグレードではバックグラウンドでそれぞれ実行されます。Jira の動作を維持する必要がある場合は、ZDU アップグレードを使用することをおすすめします。使用しているデータベースと現在の監査ログのサイズに応じて、すべてのデータを移行するには数時間かかる場合があります。

移行するエントリの数を制限する

移行を高速化するために、移行するエントリの数を制限するか移行を完全にオフにできます。移行をオフにすると決定した場合、新しい監査ログにはアップグレード後に発生したイベントのみが表示されます。 

制限を適用するには、setenv.sh/.bat ファイルに次の行を追加します。この例では、移行を 10 エントリのみに制限します。

JVM_SUPPORT_RECOMMENDED_ARGS="-Djira.advanced.audit.log.migration.limit=10"

移行の実行中は新しいイベントがバッファーに入れられて、移行が完了するとバッファーがリリースされます。移行前には追加のヘルス チェックも実行して、新しい監査ログを収容するのに十分な空きディスク領域 (Jira ホーム パーティション上) があるかどうかを確認します。

Expected changes to incoming mail settings (Jira 8.10)

In response to Google and Microsoft deprecating Basic Authentication, we will soon be adding OAuth 2.0 authentication methods for incoming email (so far using the IMAP and POP3 protocols). We’ll also backport it to the supported Enterprise releases. If you currently use email to create issues and issue comments, you will need to reconfigure your incoming mail settings. 

We treat this work with highest priority and aim to provide the solution ahead of the deadlines set by Google and Microsoft so that you have time to upgrade. 

OAuth 2.0 support will mean changes in to the incoming mail settings and the way you configure the incoming email server. It's a good idea to plan to take the time after your upgrade to review the changes so that your instance's email handlers keep working. 

 サポート終了のお知らせ

サポート終了

In Jira 8.8, we're making the following changes:

We're stopping the support for the following platforms:

  • SQL Server 2012

  • PostgreSQL 9.4

  • Solaris

  • Oracle 12c R1

  • PostgreSQL 9.5

For more details, see End of support announcements.

Deprecating Hipchat

現在、Jira バージョン 8.11 以降での Hipchat プラグインのサポートおよびバンドルの廃止を予定しています。
これは、Hipchat Cloud は 2019 年 2 月に、Hipchat Data Center は 2019 年 9 月に、Hipchat Server は 2020 年 6 月にサポートが終了されるためです。

If you have not already, make sure you migrate to other chat solutions before Jira 8.11.

 アプリ開発者向けの情報

アプリに関するすべての重要な変更については、「Jira 8.8 への準備」を参照してください。

 アップグレード手順

Jira バージョン 8.x.x からアップグレードする場合 

See Upgrading Jira applications for complete upgrade procedures, including all available upgrade methods and pre-upgrade steps. For a more tailored upgrade, go to  > Applications > Plan your upgrade. We’ll recommend a version to upgrade to, run pre-upgrade checks, and provide you with a custom upgrade guide with step-by-step instructions.


As the result of introducing the Advanced auditing feature, we'll be migrating your old audit log (up to 10 million records) on upgrade. Depending on the platform you're using and the size of your audit log, the migration might take up to several hours.

If you migrate with ZDU, your migration task will run in the background, and Jira will still be accessible to users.

You can use the jira.advanced.audit.log.migration.limit flag in the Jira properties file to limit the number of events you want to migrate or to turn off the migration altogether. In that case, you will only see the new events in your upgraded Audit log view, and the past events will remain invisible until you have performed the migration.


最終更新日 2020 年 11 月 2 日

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

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