Description: ビルド、Cloudflare Workers、公開失敗の違いを、増えすぎた確認処理の実例で解説。
Introduction
サイトを公開するだけなのに、なぜ何十分も待って失敗するのか。原因はページを作る処理そのものより、公開前に増殖した確認手順にある場合がある。
What is happening?
ビルドは記事やプログラムを表示できる形に組み立てる工程。Cloudflare Workersは、その完成品を訪問者へ届けたり、アクセス時の処理を動かしたりする。GitHub ActionsやBuildkiteはビルドと公開の命令を実行できる。役割が違うのに全部まとめて「Workerが止まった」と呼ぶと、故障箇所が迷子になる。
The absurd failure
ある公開処理では、Workerへの事前問い合わせ、最新コードへの切り替え、再実行、変更判定、無料枠の台帳、結果報告が直列につながっていた。外部の無料枠が尽きて最初の問い合わせが応答しなくなると、その確認を飛ばす設計だった。しかし次の確認でまた止まり、実際には何も公開していないのに画面には「成功」。仕事をサボったのに満点の通知表だけ提出する自動化である。
How to tell what failed
ビルドの赤いエラーが100件でも、原因は共通ファイル1個かもしれない。逆にビルドが緑でも、Workerの公開先や配信中の版が古ければサイトは更新されない。まず「ビルド」「アップロード」「本番の表示」を別々に確かめる。
A simpler route
改善案は単純だ。Workerの公開は正規の公開コマンド1本。サイトはビルドしてPagesへアップロードするコマンド1本。どの自動実行サービスも同じ命令を呼ぶ。公開しなかった場合は理由付きで失敗と表示し、最後に本番で新しい版が出ているか確かめる。
Conclusion
人の手間を消すために自動化したら、自動化の世話が本業になった。必要だったのは、もう一人の監督AIではなく、余計な関門を減らすことだった。
