The Harness ／公式情報・ツール比較

HarnessのテストとCodexレビュー｜PR・リリース判定・障害初動

· 執筆: The Harness 編集部
THE HARNESS LAB
HarnessのテストとCodexレビュー｜PR・リリース判…

リポジトリ既定の品質検査、Codexによる差分レビュー、PR自動テスト・デプロイ、リリース判定と障害初動を整理します。 forkのSecretsを守りながら、mainへ壊れた変更を入れません。 package.jsonとCIから、必要なbuild・typecheck・testを自動選択します。 修正前に、バグ・権限・データ損失・二重送信を重点レビューします。

この記事はHarness Academyの教材データを基に、各Harnessの公式リポジトリにある実装箇所と照合して構成しています。秘密情報や本番データを記事・AIチャットへ貼らず、外部送信は必ず検証対象を限定してください。

この記事の目次

    最初に確認すること

    • PRで自動テスト・自動デプロイする: PR時は検査だけ、main反映後だけ本番deployする
    • リポジトリどおりに品質検査する: 存在しないコマンドや不足した検査でリリースしない
    • Codexに差分レビューさせる: 実装者と別の視点でリリース阻害問題を見つける
    • リリース判定と障害初動: 雰囲気で本番反映せず、失敗時も同じ手順で復旧する

    PRで自動テスト・自動デプロイする

    forkのSecretsを守りながら、mainへ壊れた変更を入れません。

    この工程のゴール: PR時は検査だけ、main反映後だけ本番deployする

    LINE本家にはworker-ciと、fork向けCloudflare deploy workflowがあります。deployは本家では動かず、forkのvariableで明示有効化する設計です。

    fork由来PRへ本番Secretsを渡さないことが重要です。

    手順

    1. CI確認

    typecheck/test/buildの対象pathを確認します。

    2. Secrets設定

    fork repositoryのActions Secrets/Variablesへ必要名だけを登録します。

    3. 保護

    branch protectionとEnvironment承認を設定します。

    完了条件

    • PRでdeployしない
    • fork PRへSecretsを渡さない
    • main deployの明示条件がある

    Academy教材: Harnessの入口とCloudflareを安全にする / Lesson 9-2

    リポジトリどおりに品質検査する

    package.jsonとCIから、必要なbuild・typecheck・testを自動選択します。

    この工程のゴール: 存在しないコマンドや不足した検査でリリースしない

    ルートで何でも実行せず、変更packageとCI workflowを見て必要な検査を決めます。さらにWebhookなど重要動線は実環境スモークテストを追加します。

    手順

    1. 差分分類

    Worker、Web、DB、SDK、MCP、workflowへ分類します。

    2. 自動検査

    package scriptsとCIに存在するコマンドだけを実行します。

    3. 実通信

    変更に関係する検証用LINE/IG動線を一件確認します。

    完了条件

    • 差分に応じた検査だけを実行
    • 失敗を無視しない
    • 未検証項目が明示される

    Academy教材: テスト・Codexレビュー・障害対応 / Lesson 10-1

    Codexに差分レビューさせる

    修正前に、バグ・権限・データ損失・二重送信を重点レビューします。

    この工程のゴール: 実装者と別の視点でリリース阻害問題を見つける

    レビューでは最初にコードを直させず、重要度、発生条件、根拠行、影響、修正案だけを報告させます。

    手順

    1. 対象固定

    base branchと対象commitを指定します。

    2. read-only review

    重点リスクを渡して指摘だけを受け取ります。

    3. 一件ずつ修正

    妥当性を確認した指摘だけを別commitで直します。

    完了条件

    • 修正せず指摘だけを報告
    • 発生条件と根拠行がある
    • 重要度順に並ぶ

    Academy教材: テスト・Codexレビュー・障害対応 / Lesson 10-2

    リリース判定と障害初動

    証拠を一枚にまとめ、GO／NO-GOと障害時の初動を固定します。

    この工程のゴール: 雰囲気で本番反映せず、失敗時も同じ手順で復旧する

    GO条件はテスト成功だけではなく、rollback地点、監視、担当者、顧客影響、未解決リスクまで含みます。

    手順

    1. release sheet

    commit、差分、migration、test、deployment、rollbackをまとめます。

    2. GO/NO-GO

    重大問題や未検証があればNO-GOにします。

    3. 初動

    検知、停止、切り分け、復旧、報告を時系列で残します。

    完了条件

    • GO/NO-GOが根拠付き
    • rollback地点が特定
    • 反映後の監視項目がある

    Academy教材: テスト・Codexレビュー・障害対応 / Lesson 10-3

    公式ソース

    関連ガイド

    Academy会員はコピペ実行用プロンプトと演習を開くと、同じ手順をAIへ渡して実機で進められます。