あるポリシーポリシーとは、名前が付けられ、バージョン管理される品質ゲートのセットです。プロジェクトに適用するのはポリシーで、実際に実行されるのはゲートです。
概念については、ブロッキングとアドバイザリーの違いや、ゲートが実行される位置などをご確認ください。品質ゲートまずはこちらをご覧ください。このページではそれらの管理方法について説明します。
それらは「品質管理」で管理します。画面には組織のデフォルト設定と各プロジェクトの設定が一覧表示されます。いずれかを選択すると、新規作業のスクリーニング方法、各変更時のチェック内容、QAレベル、チェック実行場所が確認でき、切り替えスイッチもあり、オンにすぐに適用されます。確定操作で変更を取り消すことも可能で、各行の設定を変更するとそのチェックの動作が変わります。
- 組織のデフォルト設定3つのプロジェクトがこれを採用しています2件のうち5件
- ストアフロント独自の設定4件のうち5件
- ドキュメントサイトデフォルト設定に従う2件のうち5件
- 請求処理 APIデフォルト設定に従う2件のうち5件
- モバイルアプリデフォルト設定に従う2件のうち5件
- アンチスロップテストが弱まったり、エラーが無視されたり、プレースホルダーが配信されたり、構造的負債が増加した場合に変更内容を差し戻します。
- 単体テストすべての変更に対して、リポジトリ内のユニットテストを検出して実行します。
- ブラウザテスト2件のうち3件デフォルト設定と異なる変更内容に対してブラウザー上での操作を実行します。
- 翻訳デフォルト設定と異なる変更された文字列が翻訳されているか、およびプレースホルダーや複数形の表現が一致しているかを確認します。
- リポジトリチェック書式設定、ファイルサイズ、マイグレーション、統合テスト、セキュリティスキャンなど、独自のコマンドを実行します。
- 徹底したQA徹底的QAプロセスでは仕様に基づいて実際の証拠やスクリーンショットを収集します。この機能が無効な場合は標準的なQAが適用されます。
品質管理：適用されているポリシーと最新のゲート実行結果。例示用データです。
ポリシーの作成
ポリシーとは、チェックのセットであり、各チェックについて失敗時にブロッキングするかアドバイザリーとするかが定義されます。
ほとんどの組織では、プロジェクトごとに1つずつではなく、2～3種類のポリシーが必要です。
- 1つ目は厳格なポリシーで、本番環境のサービス向けに使用します。
- 2つ目は標準的なポリシーで、通常の作業全般に適用します。
- 場合によっては簡易なポリシーを内部ツールやプロトタイプ用に使用します。
それ以上の種類があると、どのプロジェクトにどのポリシーが適用されているかを誰も把握できなくなります。
組織のデフォルト設定とプロジェクト固有の設定
プロジェクトは、スイッチを変更しない限り組織のデフォルト設定に従います。その変更によりプロジェクト固有の設定がデフォルトからコピーされ、以降はデフォルトの変更が反映されなくなります。各行でデフォルトから特定のチェックをコピーしたり、プロジェクトのメニューからプロジェクト全体を組織のデフォルト設定にリセットしたりできます。スイッチの背後にある完全なポリシー（期待値、チェック間の依存関係、修復予算、バージョンなど）は、高度なエディターと同じメニューから開くことができます。デフォルトに従うプロジェクトの場合、エディターはデフォルトのコピーから起動し、公開するまでプロジェクトに変更は反映されません。
デフォルト設定を「標準的な」チェックに設定してください。これはほとんどのプロジェクトで実行すべきチェックであり、最も厳格なチェックは意図的にプロジェクトごとに選択するべきものです。
プルリクエスト
人や他のツールが作成したプルリクエストは、CoroidのCoroid GitHubアプリを通じてCoroidに届きます。プルリクエストグループが品質管理で、組織のデフォルト設定および各プロジェクトにおけるプルリクエストの処理方法を決定します。
- Coroid品質管理Coroid品質管理は上記のチェックをすべてのpull requestで実行し、その結果をGitHub上のCoroid品質管理チェックとして報告します。
- CoroidレビューCoroidレビューでは、Coroidのレビュアーが各pull requestを読み、問題のある行にコメントを付けます。このレビューはCoroid品質管理がチェックしたプルリクエストを対象とします。
Coroidレビューの設定：
- 投稿内容デフォルトのアドバイザリー設定ではコメントが投稿され、チェックは失敗しません。ブロッキング設定にすると問題が見つかった際に要求が中断され、チェックが失敗します。ブロッキングレビューでマージを停止させるには、GitHubでCoroidレビューを必須チェックに設定してください。
- 対象となるプルリクエストデフォルトでは下書き状態が完了とマークされるまで待機し、Coroidが作成したプルリクエストはスキップされます。これはCoroidのレビュアーがタスク内で既にレビューを終えているためです。ボットが作成したプルリクエストもスキップできます。
- レビュー実行タイミング最後のプッシュから一定時間（デフォルトで5分）待機してからレビューを開始し、新しいプッシュがあれば未開始のレビューはキャンセルされます。GitHubでの再実行操作で即座にレビューを開始できます。
- レビューの深さレビュアーが1回のレビューで読み書きできる範囲です。
Coroidのレビュー規則とリポジトリ内のreview-rulesフォルダーに定義された規則に従います。組織のデフォルト設定に従うプロジェクトは、他の制御と同様にデフォルトの設定が適用されます。
問題が発生した場合
組織のデフォルト設定には、失敗を各プロジェクトのフォローアップ作業に変換する3つのスイッチがあります。各スイッチで実行される自動化処理はファクトリーの自動化機能に一覧表示され、エージェントがコードを読み取ってタスクを作成します。そのタスクは他のタスクと同様に仕様定義、ビルド、検証、レビューを経て処理されます。
| スイッチ | 実行タイミング | エージェントの処理内容 |
|---|---|---|
| タスクが失敗した場合、修正タスクを作成 | タスクが失敗 | 原因を特定し、コードに問題がある場合はそれを修正するタスクを作成します。 |
| デプロイが失敗した場合、調査を実施 | デプロイが失敗 | そのバージョンで変更された内容を確認し、何が問題でどう修正すべきかを記載したタスクを作成します。 |
| リリースがロールバックされた場合、修正計画を立てる | リリースがロールバック | 何がロールバックされ、その理由は何か、再リリース前に何を変更すべきかを記録するタスクを作成します。 |
オフに切り替えるとその自動化処理は一時停止し、再びオンにすれば再開します。どの変更にも元に戻す機能が付いています。ファクトリー内の自動化処理ページでは、その処理が品質管理によって管理されていると表示されます。そこで一時停止するのもオフにするのと同じで、指示内容を変更して確認を経ると独自の処理となり、スイッチでオン/オフを切り替えられなくなります。
これらは新規作業内のテンプレートでした。以前にこれらのテンプレートから作成した自動化処理は引き続き実行されます。変更を加えていなければ、対応するスイッチをオンにすると、2つ目の処理を開始する代わりにその処理が起動します。変更を加えた場合は、その処理はユーザー専用のものとなり、スイッチの行にその名前が記載され、スイッチで管理できるようになります。
安全なリリース
ゲートにおける障害の原因は、その機能が弱いことではありません。善意から設けたブロッキングゲートが組織内のすべてのタスクを同時に停止させてしまう点にあります。
安全な手順：
- ゲートを「アドバイザリー」として追加します。。
- 実際の業務で1〜2週間ほど実行させ、何を検知するかを確認してください。
- 得られた知見に基づいて調整を行ってください。
- 「ブロッキング」に昇格させます。あるプロジェクトで設定します。
- 正常に動作することが確認できたら、より広範囲に展開してください。
- 1ゲートを追加するアドバイザリー
- 21〜2週間観察するアドバイザリー
- 3検出結果に合わせて調整するアドバイザリー
- 41つのプロジェクトでブロッキングに設定するブロッキング1つのプロジェクト
- 5より広範囲に展開するブロッキング複数のプロジェクト
バージョン管理とロールバック
ポリシーはバージョン管理されます。各スイッチで新しいバージョンが作成され、確認操作により直前のバージョンに戻すことが可能です。古いバージョンは高度なエディターのバージョン履歴から復元できます。
ロールバックがあるからこそ、リリースに関して断固とした判断を下すことが可能になります。新しいゲートの調整が不十分だった場合でも、復元は単一の操作で済み、過去のデータを掘り起こす必要はありません。
オーバーライド
権限を持つユーザーはブロッキングゲートをオーバーライドできます。オーバーライドの記録には、誰が、いつ、何に対して行ったかが残されます。
オーバーライド率を注視してください。発動するたびにほとんどの場合でオーバーライドされるゲートは、何も強制していないことになり、摩擦や書類上の記録を増やすだけです。ゲートを修正するか、削除するべきです。