品質ポリシーとゲート

「ポリシー」とはポリシー名前が付けられ、バージョン管理される品質ゲートの集合です。ポリシーはプロジェクトに適用するもので、実際に実行されるのはゲートです。

ブロッキングとアドバイザリーの違いや、ゲートが実行順序の中でどの位置に配置されるかといった概念については、以下をご覧ください。品質ゲートまずはこちらをご確認ください。このページではそれらの管理方法について説明します。

それらを管理するには品質管理その画面には組織のデフォルト設定と各プロジェクトの設定が一覧表示されます。いずれかを選択すると、新規作業がどのようにスクリーニングされるか、各変更時に何がチェックされるか、QAレベルやチェックの実行場所が確認でき、切り替えスイッチをオンにすれば即座に適用されます。確定操作で変更を取り消すことも可能で、各行の設定を変更すれば該当するチェックの動作も変わります。

ポリシーの作成#

ポリシーとはチェック項目の集合であり、各項目について失敗時にブロッキングするかアドバイザリーとするかが定められています。

ほとんどの組織ではプロジェクトごとに1つずつではなく、2～3種類のポリシーがあれば十分です。

• 「厳格なポリシーは本番環境のサービス向けです。
• 「標準的なポリシーは通常の業務全般に適用されます。
• 時には「簡易なポリシーは社内ツールやプロトタイプ向けです。

それ以上の種類があると、どのプロジェクトにどのポリシーが適用されているかを誰も覚えていられなくなります。

組織のデフォルト設定とプロジェクト独自の設定#

プロジェクトは組織のデフォルト設定に従いますが、スイッチを切り替えるとプロジェクト独自の設定が適用され、以降はデフォルト設定の変更が反映されなくなります。各行からデフォルト設定のチェックをコピーすることも可能で、プロジェクトのメニューから組織のデフォルト設定にプロジェクト全体をリセットすることもできます。スイッチの背後にある完全なポリシー（期待値、チェック間の依存関係、修復予算、バージョンなど）は、高度なエディターと同じメニューから開くことができます。デフォルト設定に従うプロジェクトの場合、エディターはそのコピーから起動し、公開するまでプロジェクトに変更は反映されません。

デフォルト設定を「標準的なチェックに設定してください。これらはほとんどのプロジェクトで実行すべきチェックであり、最も厳格なチェックは意図的にプロジェクトごとに選択する必要があります。

プルリクエスト#

人や他のツールが作成したプルリクエストは、Coroidを介してCoroid GitHubアプリに届きます。プルリクエスト品質管理グループが、組織のデフォルト設定および各プロジェクトにおけるプルリクエストの処理方法を決定します：

• Coroid品質管理Coroid品質管理は上記のチェックをすべてのpull requestに対して実行し、その結果をGitHub上のCoroid品質管理チェックとして報告します。
• CoroidレビューCoroidレビューでは、Coroidのレビュアーが各pull requestを読み、問題のある行にコメントを付けます。この処理はCoroid品質管理がチェックしたプルリクエストを対象に行われます。

Coroidレビューの設定：

• 投稿内容デフォルトの「アドバイザリー」モードではコメントのみが投稿され、チェックは失敗しません。ただし、セキュリティがセキュリティレビューを強制する場合、確認済みの重大または高リスクなセキュリティ問題が発生するとチェックが失敗します（詳細は コードスキャンとセキュリティレビューをご参照ください）。「ブロッキング」モードに切り替えると、問題が検出された際に要求がブロックされ、チェックが失敗します。ブロッキングレビューでマージを停止させるには、GitHubでCoroidレビューを必須チェックに設定してください。
• 対象となるプルリクエストデフォルトでは下書き状態のものが「準備完了」とマークされるまで待機し、Coroidが作成したプルリクエストはスキップされます。これはCoroidのレビュアーがすでにタスク内でレビューを終えているためです。ボットが作成したプルリクエストもスキップされる場合があります。
• レビュー実行タイミング最後のプッシュから一定の待機時間（デフォルトでは5分）を経てからレビューを開始します。新しいプッシュがあれば未開始のレビューは中止されます。GitHubでの再実行操作で即座にレビューが開始されます。
• レビューの深さレビュアーが1回のレビューで読み書きできる範囲です。

この設定はCoroidのレビュー規則と、リポジトリ内のreview-rulesフォルダーに記載された規則に従います。組織のデフォルト設定に従うプロジェクトは、他のコントロールと同様にデフォルト設定の内容が適用されます。

問題が発生した場合#

組織のデフォルト設定の下にある3つのスイッチをオンにすると、すべてのプロジェクトで障害発生時の対応作業が自動化されます。各スイッチで実行される自動化処理はファクトリーの「自動化」セクションに記載されており、エージェントがコードを解析してタスクを作成し、そのタスクは他のタスクと同様に仕様定義、ビルド、検証、レビューのプロセスを経ます。

オフにするとその自動化処理が一時停止し、再びオンにすると再開されます。 すべての変更には元に戻す機能が付いています。ファクトリー内の自動化処理ページでは、それが品質管理によって管理されていると表示されます。 そこで一時停止するのもオフにするのと同じで、指示を変更して確認を得れば独自の設定になり、スイッチでオン/オフを切り替えることはできなくなります。

これらは新規作業内のテンプレートでした。以前にテンプレートから作成した自動化処理は引き続き実行されます。 変更を加えていなければ、対応するスイッチをオンにすると、新たな処理を開始する代わりにその自動化処理が使われます。変更を加えた場合は、それは自分専用の設定となり、スイッチの行にその名前が記載され、スイッチで管理できるようになります。

安全なリリース#

ゲートの問題点は、その機能が弱すぎることではありません。意図的とはいえ、ブロッキングゲートが組織内のすべてのタスクを同時に停止させてしまうことです。

安全な手順は次の通りです：

1. ゲートを「助言用。
2. 実際の業務で1〜2週間ほど実行させ、検出された内容を確認してください。
3. 得られた知見に基づいて調整を行ってください。
4. 「ブロッキング」に昇格させ、1つのプロジェクトで適用します。
5. 正常に動作することが確認できたら、より広範囲に展開してください。

バージョン管理とロールバック#

ポリシーはバージョン管理されます。各スイッチで新しいバージョンが作成され、確認を経て元のバージョンに戻すことでロールバックできます。古いバージョンは高度なエディターのバージョン履歴から復元可能です。

ロールバック機能があるからこそ、リリースに関して断固とした判断を下すことができます。新しいゲートの設定が不適切だった場合でも、元に戻すのは単一の操作であり、複雑な調査をする必要はありません。

上書き設定#

権限を持つユーザーはブロッキングゲートを上書き設定できます。上書きされた内容は、誰がいつ何に対して行ったかが記録されます。

上書き率を注視してください。ゲートが発動するたびにほとんど上書きされる場合、それは何も強制していないことになり、むしろ摩擦や余計な記録を生み出すだけです。ゲートを修正するか、削除するべきです。

関連項目#

• 品質ゲート（概念）
• チェック項目、実行結果、検出事項
• レビュー証拠を確認