Copy

このプラクティスでは、オープンソースのデモを使って、QoderWake が GitHub のイベントにどのように応答するかを示します。Release、Developer、Reviewer、Tester の各 Waker が 1 回のデリバリーで協力し、GitHub が要求、コード、品質の証拠を保持します。コードのマージと本番リリースの承認は、引き続き人が行います。このデモは、製品評価、ソリューション検証、チーム向けデモのために使用してください。実際のプロジェクトにこの設計を適用する前に、ブランチ戦略、品質ゲート、アクセス制御ポリシーに合わせて調整してください。

デリバリーフローの理解

GitHub のイベントが担当の Waker を起動します。コード PR とリリース PR の両方に手動マージゲートが残ります。

Waker	責任範囲	行ってはならないこと
Release	イテレーションブランチの作成、リリース PR の準備、タグと GitHub Release の作成、マイルストーンクローズ	プロダクトコードの変更、ユーザーの代わりに PR をマージすること
Developer	要求と受け入れ基準の読み取り、変更の実装とテスト、コード PR の作成または更新	自分のコードレビューを承認すること
Reviewer	現在の head SHA の diff を読み取り、CI を確認し、独立したテストを実行し、レビュー結果を書き戻すこと	コードの変更、PR のマージ
Tester	コードがイテレーションブランチに入った後、独立した受け入れテストを実行する。テストが失敗した場合、再現の証拠を添えてバグを作成する	失敗をスキップしたり、偽りの合格を報告したりすること

テストでバグが見つかった場合、フローは Developer に戻り、実装、レビュー、手動マージ、テストを繰り返します。リリース準備は、テストに合格した後でのみ開始されます。

環境の準備

デモを実行する前に、以下を用意してください。

Node.js 20 以降、Git、GitHub CLI。
すでにサインイン済みの、稼働中の QoderWake インスタンス。
Waker と Autonomous Work を作成できる QoderWake アカウント。
対象リポジトリ、GitHub Actions、Actions Secrets を管理できる GitHub アカウント。
API トリガー型の Autonomous Work を呼び出すための Personal Access Token（PAT）。トークンの作成と保存に関するガイダンスは API トリガーの設定を参照してください。

初回の実行では、本番リポジトリに接続する代わりに、専用のテストリポジトリと範囲を絞ったテスト用権限を使用してください。

デモのダウンロードと起動

QoderWake × GitHub DevOps Demo リポジトリを開き、Releases から最新のソースパッケージをダウンロードします。
Windows の場合は Windows Source パッケージ、macOS または Linux の場合は macOS/Linux Source パッケージを選択し、ローカルで展開します。
QoderWake が稼働していてサインイン済みであることを確認します。
展開したディレクトリから、オペレーティングシステムに対応するコマンドを実行します。

macOS または Linux:

./start-demo

Windows:

.\start-demo.cmd

ソースパッケージは直接実行できます。コンパイルしたり npm install を実行したりしないでください。オペレーティングシステムがスクリプトをブロックする場合は、システムのセキュリティ管理を無効にする代わりに、ファイルの権限とターミナルのセキュリティプロンプトを確認してください。

初回設定の完了

ターミナルのウィザードに従ってください。

GitHub にサインインし、現在のアカウントと対象リポジトリを確認します。
ローカル作業ディレクトリを選択または作成します。ディレクトリが存在しない場合、ランチャーがそれを作成し、デモリポジトリをクローンします。
マスクされた入力欄に QoderWake PAT を入力します。トークンをリポジトリファイル、Waker の指示、通常ターミナルログに貼り付けないでください。
プロンプトが表示されたら、Release、Developer、Reviewer、Tester の各 Waker を作成または再利用します。
4 つの API トリガー型 Autonomous Work と、それぞれの呼び出し URL が作成されたことを確認します。
ランチャーが PAT と 4 つの Waker 呼び出し URL を GitHub Actions Secrets に保存することを許可します。
デモのワークフロー、イベントルーター、CI、ステータスラベルが準備できていることを確認します。

ウィザードが完了したら、各 Waker の Autonomous Work を開きます。それが有効になっていて、期待されるワークスペースと API トリガーを使用しており、説明に実際の認証情報が含まれていないことを確認してください。

GitHub Actions がイベントをフィルターして転送し、4 つの API トリガー型 Autonomous Work がそれぞれの責任を持つ Waker を起動します。

完全なデリバリーフローの実行

初回の実行では、1 件のバグが見つかるオプションを選択します。これにより、失敗したテストが正しく開発に戻ることを検証します。

Requirement → Developer → code PR → Reviewer → manual merge
→ Tester → bug → Developer fix → Reviewer re-review → manual merge
→ Tester retest → release PR → manual merge → tag / GitHub Release

ステージ	システムが実行すること	ユーザーが確認すること
イテレーション開始	Release Waker がマイルストーン、イテレーションブランチ、要求を作成します	要求と受け入れ基準を確認します
実装	Developer Waker がブランチを作成し、コードを変更してテストし、コード PR を開きます	PR 内の要求リンクとテストの証拠をレビューします
レビュー	Reviewer Waker が現在のリビジョンを独立してレビューし、同時に GitHub Actions が CI を実行します	Reviewer が合格し CI が成功した後でのみコード PR をマージします
テストと修正	Tester Waker が受け入れテストを実行します。失敗するとバグが作成され Developer を起動します	バグの再現手順、期待される結果、実際の結果を確認します
リリース	Release Waker が要求、バグ、PR、CI の証拠を集め、リリース PR を開きます	リリース PR をレビューしてマージします
完了	Release Waker がタグと GitHub Release を作成し、マイルストーンをクローズします	バージョン、リリース内容、マイルストーンの状態を確認します

ターミナルには、現在のステージ、アクティブな Waker、ライブセッションリンク、次の手動アクションが表示されます。フローが予期せず停止した場合は、まずターミナルのプロンプトを読み、続いて対応する QoderWake セッションと GitHub オブジェクトを開いて、記録された事実を比較してください。

主要ステージの確認

Developer が要求を受領する

Release Waker がイテレーションブランチを作成した後、要求は開発フローに入ります。ターミナルは Developer ステージに進み、ライブセッションリンクを表示します。

ターミナルは Developer が要求を実装している様子を表示し、ライブセッションリンクを提供します。

手動マージの前に Reviewer と CI が合格する

Developer がコード PR を開いた後、Reviewer は現在のコードリビジョンのみを評価します。Reviewer と CI の両方が合格すると、ターミナルは手動マージゲートで停止し、ユーザーがコード PR をマージするかどうかの判断を待ちます。

ターミナルは手動マージが必要なコード PR を示します。Tester はマージ後にのみ開始します。

ライブセッションを開き、Reviewer が PR、リンクされた要求、ターゲットブランチ、head SHA を読み取り、独立したテストを実行することを確認してください。

Reviewer セッションには、テストプロセス、レビュー判断、GitHub への書き戻し結果が保持されます。

GitHub PR には、要求リンク、ブランチ、変更の説明、テストの証拠を保持してください。「完了」した QoderWake セッションだけを、十分なデリバリー証拠として扱わないでください。

コード PR はその変更の事実ページであり、マージするかどうかを判断するのは依然としてユーザーです。

Reviewer は、リビジョン固有の Review Summary を PR に書き戻すべきで、テスト、lint、CI、受け入れ基準、diff の範囲をカバーします。

レビュー結果は特定のリビジョンを識別します。コードの更新には新しいレビューが必要です。

さらに、GitHub Actions CI ジョブが成功することも確認してください。Reviewer の合格は独立した CI の代わりにはならず、マージゲートの前に両方の結果が合格している必要があります。

GitHub Actions が独立したテストゲートを提供します。

Tester がバグを作成して Developer に返す

コードがイテレーションブランチに入った後、Tester は独立した受け入れテストを実行します。テストが失敗すると、Tester は再現の証拠を添えてバグを作成し、タスクを Developer に戻します。

バグは実装、レビュー、手動マージ、再テストに再投入されます。

Release が公開を完了してイテレーションをクローズする

再テストに合格した後、Release Waker はリリース PR を開きます。ユーザーがそれをマージすると、Release Waker はタグと GitHub Release を作成し、マイルストーンをクローズします。

ターミナルが 9/9 に達し、リリースが公開されイテレーションがクローズされたことを確認します。

結果の検証

完全な実行の終わりに、以下を検証してください。

GitHub に、この実行専用のマイルストーン、要求、コード PR、テスト記録、リリース PR が存在する。
Reviewer の結果が、古いリビジョンではなく現在の PR head SHA を識別している。
フローが手動マージゲートに到達するのは、CI と Reviewer の両方が合格した後のみである。
バグ経路では、バグに再現の証拠が含まれ、実装、レビュー、再テストに再投入されている。
正しいタグと GitHub Release が存在し、マイルストーンがクローズされている。
4 つの QoderWake 実行が関連する GitHub オブジェクトに対応付けられており、セッション、スクリーンショット、ログに認証情報がない。

デモが中断された場合は、ソースパッケージディレクトリで npm run watch を実行して進捗監視を再開してください。ローカルのチェックアウトが削除されている場合は、ランチャーを再起動すると、リモートリポジトリから復元 TRY 行われます。リモートリポジトリが存在しない場合や現在のアカウントがアクセスできない場合は、まずリポジトリまたはアクセスの問題を修正してください。

設計を実際のデリバリーシステムに適用する

デモの権限とトリガーフィルターを本番に直接コピーしないでください。イベントアダプターと事実読み取りツールを、お使いのデリバリープラットフォームの対応するコンポーネントに置き換えてください。

デモにおける GitHub の機能	別のシステムでの同等物
Issue / Milestone	要求、欠陥、イテレーション管理
Pull Request イベント	GitLab Merge Request、Codeup コードレビュー、または同等のイベント
GitHub Actions ルーター	エンタープライズ CI、イベントバス、または自動化パイプライン
GitHub CLI	プラットフォームの公式 CLI または OpenAPI
Actions Secrets	エンタープライズの認証情報ボールトまたはシークレットマネージャー

移行後もこれらの管理を維持してください。

各 Waker に明確な責任を 1 つ与え、実装、レビュー、テスト、リリースを独立させてください。
意味のあるビジネスイベントでのみトリガーし、コメント、更新、無関係な状態変化をフィルターしてください。
以前のセッションを信頼する代わりに、毎回、要求、コード、CI、現在の状態を再読み取りしてください。
一意のイベント識別子とビジネスマーカーを使用して重複作業を防ぎ、繰り返しのデリバリーを安全に無視できるようにしてください。
コード、レビュー、バグ、テスト、リリースの結果をデリバリーシステムに書き戻し、チャットは実行の観察にのみ使用してください。
認証情報は保護されたシークレットにのみ保存し、本番のマージとリリースには人間の承認を維持してください。

このプラクティスは、オープンソースプロジェクトの Demo Flow Guide を元に変更しています。現在のスクリプト、バージョン要件、ダウンロードパッケージについては、最新のプロジェクトリリースノートを参照してください。

​デリバリー フローの理解

​環境の準備

​デモのダウンロードと起動

​初回設定の完了

​完全なデリバリー フローの実行

​主要ステージの確認

​Developer が要求を受領する

​手動マージの前に Reviewer と CI が合格する

​Tester がバグを作成して Developer に返す

​Release が公開を完了してイテレーションをクローズする

​結果の検証

​設計を実際のデリバリー システムに適用する