送客計測WorkerをデプロイCIに配線する
今回やったこと
送客計測を担うWorkerの配信経路を、手作業のコマンドだけに頼る状態から、変更を検知して検証・配信するCIへ接続した。ここで扱うのは、Workerそのものの機能追加ではなく、既に存在する処理を「変更したときに実際に配信される」経路へ載せる作業である。
最初に見つかったのは、Workerが存在していても配信の自動化が存在しない状態だった。対象は5本あり、CIにも常駐ジョブにも配信する脚がなく、配信状態を監視する一覧にも含まれていなかった。個々のソースを開いても異常は見えない。欠けていたのはコードの中ではなく、コードと運用をつなぐ配線だった。
「テストがある」と「テストが走る」は別
この差を埋めるため、Workerの一覧を worker_deploy.sh --list から取得し、デプロイ用ワークフローで同じ一覧を処理する形にした。Workerの置き場所は一つではない。通常のディレクトリに加え、別のサイト配下に置かれたWorkerもあり、単純な cloudflare-workers/*/ の検索では対象から漏れる。実際に追加された送客Workerも、別ディレクトリにあったため、対象パスの明示が必要だった。
ワークフローは Pull Request と main への push の両方で対象パスを見て起動する。ワークフロー内では一覧に含まれる各Workerのテストを実行し、関連する配信スクリプトの構文も確認する。配信一覧に載せるだけでは十分ではない。変更を加えたときにCIが起動し、配信前の確認が実行されるところまでつながって初めて自動化と呼べる。
変更ファイル
↓ paths に一致
CI が起動
↓ worker_deploy.sh --list
対象一覧を検証・テスト
↓
配信経路へ接続
対象漏れをどう防ぐか
回帰テストは、実ディレクトリ、配信スクリプトの一覧、監視対象、ワークフローの paths を突き合わせる。Pull Request 用と push 用の両方に対象があるか、一覧にある全ディレクトリがCIの起動条件に含まれるかも確認する。こうすると、新しい場所へWorkerを置いたとき、配信表だけを更新してCIの起動条件を忘れる、といった不整合を検出できる。
さらに、CIにテストファイルがあること自体を合格条件にはしない。そのテストをワークフローが呼び出すかを調べる。テストコードがリポジトリに存在しても、実行されなければ変更を止めないからだ。表・監視・実装・ワークフローを一緒に照合することで、どこか一つだけ更新された状態を見つけやすくした。
実装状況と残る注意
現在のワークフローは、対象の配線テストに加え、配信成否の判定、トークンの権限確認、本番版の読み取り、送客リンクの存在確認、各Workerの単体テストを実行する。配信の成否をコマンドの終了コードだけで決めない検証も含まれている。ここで確認できるのは、リポジトリに記されたCI構成と回帰テストの内容であり、特定の実行回における外部サービス側の配信結果を示すものではない。
技術記事で「CIに配線した」と書くとき、ワークフローファイルの追加だけを根拠にしないことが大切だ。変更パスが起動条件に入り、テストが実際に呼ばれ、対象一覧に漏れがないことまでを確認対象にする。仕組みの存在と、仕組みが動く経路の存在は別々に点検する必要がある。
更新履歴
- 2026-10-10: 初稿作成。リポジトリ内のワークフローと回帰テストをもとに構成。