This is the documentation for Crucible 3.4. View the latest version of

Unknown macro: {spacejump}

or visit the latest Crucible documentation home page.

要約


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


バグを報告


Developing an app (add-on) for an Atlassian product or using one of our APIs? Report any related bugs in our Ecosystem Jira.

On this page:

バグ レポート

Atlassian Support is eager and happy to help verify bugs—we take pride in it! Create an issue in our support system, providing as much information as you can about how to replicate the problem you're experiencing. We'll replicate the bug to verify, then lodge the report for you. We'll also try to construct workarounds if possible.

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

Use our public issue tracker to search for existing bugs, add your report, and watch the ones that are important to you. When you watch an issue, we'll send you an e-mail notification when the issue's updated.

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

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

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

重大度 1 - Critical

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

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

重大度 2 - Major

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

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

重要度 3 - Minor

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

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


Assessing bugs using symptom severity makes sure that we prioritise the most impactful fixes. We give high priority to security issues.

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

If you watch or mark a bug as affecting your team, it’s useful to understand how we review, prioritize, and resolve them in our public issue tracker jira.atlassian.com.

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

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

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

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

確認
Gathering impact

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

優先付け

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

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


Ready for development

この課題の修正が必要で、開発チームは実装を開始する準備が整っています。


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

実装

In review

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


Waiting for release

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


Closed

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

クローズ

バグ修正を適用する方法

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

Data Center 製品のリリースに関連する用語

  • プラットフォーム リリース (例: 4.0) には、重大な変更や大幅な変更が含まれます。これには、既存の API の変更や削除、ユーザー エクスペリエンスの重大な変更、主要な機能の削除などが含まれます。

  • フィーチャー リリース (例: 4.6) には、新機能、既存機能の変更、サポートされるプラットフォーム (データベース、オペレーティング システム、Git バージョンなど) の変更、または機能の削除などが含まれます。これらはこれまでは、ほとんどの製品で "メジャー" リリースと呼ばれていました。

  • バグ修正リリース (例: 4.6.2)にはバグの修正、安定性やパフォーマンスの改善が含まれます。修正の内容によっては既存の機能への小規模の変更が行われる場合がありますが、新機能やリスクの高い変更は含まれないため、ユーザーはすぐに利用を継続できます。バージョンの最新のバグ修正リリースへの定期的なアップグレードを行うことをお勧めします。これらはこれまでは、ほとんどの製品で "メンテナンス" リリースと呼ばれていました。

3 つの主なリリース タイプに加え、フィーチャー リリースが長期サポート リリースに指定される場合もあります。つまり、標準のフィーチャー リリースよりも長い期間、バグ修正を利用できます。

長期サポート リリース

長期サポート リリース (旧称 Enterprise リリース) は、新しいフィーチャー バージョンへのアップグレードの準備に時間を要し、クリティカルなバグの修正を適用する必要がある、Data Center 製品ののお客様向けに用意されています。新しいフィーチャー バージョンへのアップグレード頻度がおよそ年に 1 回の組織では、長期サポート リリースのほうが適している場合があります。当社の Jira Software、Confluence、Bitbucket、Bamboo への対応は次のとおりです。

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

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

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

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






その他の情報

See Atlassian Support Offerings for more support-related information.

  • ラベルなし

 

 

 Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.