証拠を使ってTaigaのデリバリーをレビューする

Initiativeの成果から始める

架空の備品サービスでは、従業員が自分の申請を見られるようになりました。Initiativeの成果と範囲から、レビューを始めます。成立すべき条件と、変更してはいけないものを特定します。

このデリバリーでは、従業員が別の従業員の申請を読めてはいけません。マネージャーは、定義されたアクセスを維持する必要があります。ページを開くだけのテストでは、どちらの条件も証明できません。

Runsページは、失敗を含む試行を記録します。各runは、実行した計画を特定します。Runのページは調査用の記録です。作業を変える判断は、initiativeで行います。

テストとフォーマットの各ステップの証拠を読みます。Taigaは、失敗したチェックや未実行のチェックを明示します。レビューの要約で、「未実行」を「成功」に変えないでください。

アクセスモデル、スキーマ、環境、外部サービスについての前提を探します。公開された意図と実際のコードに照らして比較します。

備品サービスでは、申請の所有者をどこで確認するかを調べます。アクセスが許可された申請、別の従業員の申請、存在しない申請をテストします。ログが、申請の機密内容を明かさないことを確認します。

テストの変更もレビューします。不具合を検出するアサーションを削除していたら、テストの成功が持つ価値は限られます。ワークフローとテスト設定の変更も、レビュー対象に含めます。

振る舞い、期待する結果、必要な証拠を示します。例えば、「このエンドポイントはログインを確認していますが、申請の所有者を確認していません。サーバー側のアクセスチェックと、別の従業員の申請を使うテストを追加してください」と伝えます。

Taigaは、pull requestのレビューフィードバックと失敗したチェックに、同じブランチ上の変更で対応できます。更新後は、新しいコミットとそのチェックを確認します。以前の証拠は、変更後の成果物を対象にしていないかもしれません。

計画が未完了だったり、チェックが弱められたりしてrunが停止した場合は、示された理由を読みます。見えているチェックの要約が成功状態というだけで、draft状態を解除しないでください。

どの基準を検証済みで、どれが未解決かを記録します。リポジトリの必須レビューとチェックで、マージの境界を強制します。別のリリース判断がある場合は、それを維持します。

Taigaは、自社のパイプラインが実行したデプロイを観測します。ユーザーに変更が利用できると伝える前に、環境と成果物を検証してください。デプロイが失敗すると、以前に成功したバージョンが、引き続きトラフィックを処理している場合があります。

サービスレベルの確認で成果を確かめます。従業員が機能を使え、権限のないアクセスが拒否され、運用責任者が障害を観測できることを確認します。続いて、中断への対応を学んでください。