バグ修正ポリシー

このページの内容

お困りですか?

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

コミュニティに質問

要約

  • アトラシアンのサポートチームは、回避策の発見やバグの報告を支援します。
  • アトラシアンでは通常、重大なバグは次回のメンテナンス リリースで修正します。
  • クリティカルではないバグについては、さまざまな事項を考慮して修正予定を計画します。


バグを報告


アトラシアン製品のアプリ (アドオン) を開発していたり、弊社の API を使用していたりしますか? 関連バグを、アトラシアンの Ecosystem Jira でお知らせください。

バグ レポート

アトラシアン サポートはバグの特定を支援します。サポート システムで課題をご作成ください。 その際、ご自身が経験している問題を再現する方法について、できるだけ多くの情報を提供してください。アトラシアン サポートでは、バグを再現して検証し、お客様のためにバグ レポートを起票します。また、回避策を可能な限りお調べします。

既存のバグ レポートの検索

既存のバグを検索したり、バグを報告したりするには、アトラシアンの公式の課題トラッカーを使用できます。ご自身にとって重要な課題が見つかった場合、 ウォッチすることをご検討ください。課題をウォッチすると、課題の更新時にメール通知をお送りします。

アトラシアンでのバグ修正へのアプローチ

バグ修正リリースはフィーチャー リリースよりも頻繁に提供され、お客様に影響する最も重大なバグを対象とします。バグ修正リリースの表記は、バージョン番号の最後の数字で示されます (6.0.1 の 1 など)。

各バグは、問題の重要度 (つまり、このバグが問題を起こす場面、問題の影響範囲など) に基づいて評価されます。問題の重大度には 3 つのレベルがあります。

重大度 1 - クリティカル

アプリケーションが利用できない。ユーザーが業務を実行できず、利用できる回避策がない。 

例...
  • すべてのユーザーのログイン不可
  • すべてまたはほとんどのページの表示不可
  • メモリ不足エラーによるアプリケーション障害
  • 重大なデータ損失
  • ノード通信の失敗
  • 管理ツールの失敗 

重大度 2 - メジャー

1 つの機能の利用不可、アプリケーション速度の大幅な低下、またはユーザーの業務実行の一部の実行不可。

例...
  • アプリケーション速度の低下、断続的な失敗
  • アプリケーションは機能しているが、頻繁に使用するガジェットやマクロが機能しない
  • アプリケーション リンクの失敗
  • 特定の編集機能の失敗
  • または、実行可能な回避策がある重大度 1 (クリティカル) の課題 

重要度 3 - マイナー

アプリケーションまたは特定の機能が期待どおり動作しないが、利用可能な回避策がある。ユーザー エクスペリエンスが損なわれるが、業務は実行可能。 

例...
  • 一部の検索の失敗
  • ページのセクションの読み込み速度の低下
  • 管理機能が断続的に失敗するが、回避策を利用可能
  • 表示に不具合があるが、機能には影響しない
  • 翻訳またはローカライゼーションの軽微な問題
  • キーボード ショートカットが期待通り動作しない


バグの評価に問題の重大度を使用することで、最も影響の大きい修正を優先しています。アトラシアンでは、セキュリティの問題を最優先に位置づけています。

アトラシアンのバグ修正ワークフローについて

チームに影響をおよぼしているバグをウォッチしたり確認したりす場合、アトラシアンの公式の課題トラッカーである jira.atlassian.com における、アトラシアンのバグの確認、優先付け、および解決ポリシーをご確認ください。

アトラシアンでは、各課題に対して個別に計算される User Impact Score (UIS) という指標を使用して課題の優先順位を決定します。これは、影響を受けているユーザーの数、課題の重要度、直近での関心度、インスタンスで影響を受けるユーザーの割合に基づきます。UIS が高ければ高いほど、課題の影響範囲が大きく、重大であると見なされます。

また、お客様が課題の状況を確認しやすいよう、サーバーおよびデータセンター製品でワークフロー ステータスを標準化しました。現在のワークフローと、各ステータスの説明は次のとおりです。

ワークフロー ステータス 定義 フェーズ
Needs triage

この課題はアトラシアンの製品チームによる確認待ちです。一般に、直近で作成された課題のみがこのステータスになります。アトラシアンの製品チームはこのような課題を定期的に確認しています。

確認
Gathering impact

この課題の確認は完了しましたが、問題の影響範囲を確認するための追加情報が必要な状態です。

優先付け

Long term backlog この課題の修正が必要であることを確認していますが、先の段階で行われる予定です。これは、この課題がほかの課題と比べて重大度や影響範囲が小さいためです。
Short term backlog

この課題の修正が必要であることを確認しており、近い将来に優先的に行われる予定です。これは、この課題がほかの課題と比べて重大度や影響範囲が大きいためです。


In progress 開発チームが現在この課題に取り組んでいます。

実装

In review

この課題の修正が提案され、開発チームによるレビューおよび品質テストが行われています。


Waiting for release

この課題の修正が実装され、リリースでの提供待ちです。

クローズ

Closed

この課題に対する作業が完了しました。修正済みの場合、解決状況は "Fixed" になり、修正を含む製品バージョンを "Fixed Version" フィールドで確認できます。コードの変更が不要だった場合、解決状況は "Duplicate"、"Won't fix"、"Handled by support"、"Timed out" などになります。


バグ修正を適用する方法

バグ修正を適用するには、修正を含むリリースにアップグレードする必要があります。

リリースに関連する用語

バグ修正ポリシーを分かりやすくするための、いくつかの定義を紹介します。

  • Platform release (4.0) contains significant or breaking changes. For example changes or removal of existing APIs, significant changes to the user experience, or removal or a major feature.
  • Feature release (4.6) can contain new features, changes to existing features, changes to supported platforms (such as databases, operating systems, Git versions), or removal of features. These were previously referred to as 'major' releases by most products.
  • Bug fix release (4.6.2) can contain bug fixes, stability and performance improvements. Depending on the nature of the bug fixes they may introduce minor changes to existing features, but do not include new features or high risk changes, so can be adopted quickly. We recommend regularly upgrading to the latest bug fix release for your current version. These were previously referred to as 'maintenance' releases by most products.

In addition to the three main release types, a feature release can also be designated an Enterprise release, which means it will receive bug fixes for a longer period of time than a standard feature release.

エンタープライズ リリース

エンタープライズ リリースは、新しいフィーチャー バージョンへのアップグレードの準備に時間が必要で、重要なバグの修正を適用する必要がある、Server および Data Center のお客様向けです。新しいフィーチャー バージョンへのアップグレード頻度がおよそ年に 1 回の組織では、エンタープライズ リリースが適している場合があります。Jira Software および Confluence では、次のようになります。

  • 1 つのフィーチャー リリースをエンタープライズ リリース として指定します (最低でも 12 か月に 1 回)。
  • 最新のセキュリティ バグ修正ポリシーに記載されているように、重要なバグ修正をバックポートし、安定性、データの整合性、および重要なパフォーマンスの問題に関連する修正が適用されます。
  • 対象バージョンのバグ修正リリースを、サポート終了まで提供します。 
  • アップグレードを円滑に行えるよう、1 つのエンタープライズ リリーズと次のエンタープライズ リリースの間のすべての変更の変更履歴を提供します。

すべてのバグ修正がバックポートされるわけではありません。安定性、データの整合性、またはパフォーマンスの問題に焦点を当て、最も重要と思われるバグやリグレッションのみを対象にします。API、サードパーティ アプリ (アドオン) で使用するコード、またはインフラストラクチャに変更を加える必要がある修正 (これらは通常はプラットフォーム リリース用に予約されます) や、リスクおよび複雑性の高い修正については、バックポートを行わないことがあります。

Jira Software Data Center のお客様について、1 つのエンタープライズ リリースと次のエンタープライズ リリースの間ではゼロダウンタイム アップグレードを利用できるように考慮しますが、変更の性質によってはダウンタイムが必要になる場合があります。ゼロダウンタイム アップグレードを使用できるかどうかを変更履歴で確認できます。

この例では、バージョン 4.2 がエンタープライズ リリースとして指定されています。以下の図に示すバグ修正リリースの番号とタイミングは一例です。リリース頻度は各製品で異なる場合があります。




その他の情報

サポートに関連する情報の詳細については、「アトラシアン サポートの提供について」を参照してください。

最終更新日 2018 年 3 月 26 日

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

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