アトラシアンの Data Center 製品のバグ修正ポリシー
バグ レポート
アトラシアン サポートはバグの特定を支援します。サポート システムで課題をご作成ください。 その際、ご自身が経験している問題を再現する方法について、できるだけ多くの情報を提供してください。アトラシアン サポートでは、バグを再現して検証し、お客様のためにバグ レポートを起票します。また、回避策を可能な限りお調べします。
既存のバグ レポートの検索
既存のバグを検索したり、バグを報告したりするには、アトラシアンの公式の課題トラッカーを使用できます。ご自身にとって重要な課題が見つかった場合、 ウォッチすることをご検討ください。課題をウォッチすると、課題の更新時にメール通知をお送りします。
アトラシアンでのバグ修正へのアプローチ
バグ修正リリースはフィーチャー リリースよりも頻繁に提供され、お客様に影響する最も重大なバグを対象とします。バグ修正リリースの表記は、バージョン番号の最後の数字で示されます (6.0.1 の 1 など)。
各バグは、問題の重要度 (つまり、このバグが問題を起こす場面、問題の影響範囲など) に基づいて評価されます。問題の重大度には 3 つのレベルがあります。
重大度 1 - Critical
アプリケーションが利用できない。ユーザーが業務を実行できず、利用できる回避策がない。
重大度 2 - Major
1 つの機能の利用不可、アプリケーション速度の大幅な低下、またはユーザーの業務実行の一部の実行不可。
重要度 3 - Minor
アプリケーションまたは特定の機能が期待どおり動作しないが、利用可能な回避策がある。ユーザー エクスペリエンスが損なわれるが、業務は実行可能。
バグの評価に問題の重大度を使用することで、最も影響の大きい修正を優先しています。アトラシアンでは、セキュリティの問題を最優先に位置づけています。
アトラシアンのバグ修正ワークフローについて
チームに影響をおよぼしているバグをウォッチしたり確認したりする場合、アトラシアンの公式の課題トラッカーである 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 が長期サポート リリースとして指定されています。以下の図に示すバグ修正リリースの番号とタイミングは一例です。リリース頻度は各製品で異なる場合があります。
