反映コマンドの前にチェックを割り込ませた話：ズレを未然に防ぐ
📌 記事の取り扱いについて（公開当時の内容を含みます — タップで詳細）
本記事は公開当時の体験・気づきをまとめたものです。現在のツール数・プラン数・対象年齢・記事数・仕様とは異なる場合があります。最新の内容は各ツールページをご確認ください。ツールや外部サービスの仕様・料金は変更されることがあるため、利用前には各公式情報も併せてご確認ください。記載に誤りを見つけられた場合はお問い合わせフォームよりご連絡いただけると助かります。
公開サイトを古い状態で上書きしてしまった事故をきっかけに、反映コマンドの前にチェックが自動で割り込む仕組みを入れてみました。私は勝手に 反映前の見張り役 くらいの気持ちで呼んでいます。
仕組み自体はとても地味なのですが、入れてからは、少なくとも同じ種類の事故は起きていません。気合や記憶力ではなく、機械に防いでもらう という方針の一例として、ここに残しておきます。
どんな仕組みか
実体は、シェルスクリプトに近い小さなチェック処理です。wrangler pages deploy（私のなかでは「反映コマンド」）のような特定のコマンドを実行しようとしたタイミングで、自動で間に割り込んできて、
- いま自分が居るフォルダがちゃんと Git の置き場になっているか
- その手元が、リモートのGitとどれくらいズレているか
- まだ保存(コミット)していない変更が残っていないか
をチェックして、危なそうな状態なら警告を出し、大丈夫そうなら通す、という流れらしいです。
特に**「リモートのGitより手元が古いとき」は、警告ではなく反映そのものを止める**ようにしました。これがまさに事故の原因になったパターンなので、ここで一回止まってくれれば再発を防ぎやすくなります。保存（コミット）し忘れた変更が残っているときも、同じように止まります。
どこに仕掛けるか
割り込ませる場所は、いくつか候補がありました。素人なりに迷ったところです。
- シェル関数で
wranglerを上書きする: 簡単そうだけど、別のターミナルや別環境だと効かないことがありそう - push の時点で止める方式にする: 今回防ぎたいのは「古い手元から反映すること」なので、push 前後のチェックだけでは足りなさそう
- 開発用ツールの設定で、コマンドを実行する前にチェックを挟む: 同じ手順で動かす限り、環境が変わっても効いてくれそう
最終的には、3番目で組みました。決まった場所にチェック用のスクリプトを置いておくと、私の運用では、コマンドを実行する前にそこを通る形にできました。
チェックの中身
スクリプトの中でやっていることは、ざっくり次のような感じらしいです。
- いまのフォルダで、まずリモートの最新情報を取りに行く
- 手元と、リモートのGitとで、どれくらいズレているかを見る
- 手元のほうが古ければ、警告メッセージを出して止める
- まだ保存（コミット）していない変更があれば、それも一緒に警告する
- 何も問題がなければ、いつも通り処理を続ける
逆に、手元のほうが新しいだけの場合（つまり「まだリモートにはない変更を、これから反映したい」場合）は、そのまま通します。これは普通の流れなので、ここで止められるとかえって邪魔になってしまいます。
警告メッセージの工夫
警告メッセージは、なるべく次に何をすればいいかが分かる文面 にしてみました。
たとえば「手元が公開済みより古い」ときは、
ローカルが remote より N コミット遅れています。
古い内容で反映してしまう可能性があるため停止します。
復旧: git pull origin main を実行してから再度デプロイしてください。のように、原因とやることをセットで書くようにしています。寝起きや疲れているときにこれを見ても、迷わず直せる文面にしたかったんです。
ハマったポイント
入れるときに、いくつかつまずいた点もありました。
1. どのコマンドに割り込むかの見分けが、意外と細かい
「反映」と一文字違いのような、見るだけのコマンド（過去の反映履歴を一覧するようなもの）にも同じ言葉が含まれていて、最初はそちらにまで見張り役が反応してしまいそうでした。実際に公開内容が変わるコマンドのときだけ割り込むように、コマンドの文字の並びをけっこう細かく見分けています。ここを雑にすると、ただ確認したいだけの場面でいちいち止められて、仕組みごと嫌になってしまうので。
2. 毎回リモートに聞きに行くので、数秒待たされる
チェックのたびにリモートの最新情報を取りに行くので、反映のたびに数秒の待ちが入ります。前回の結果を覚えておいて省く手も考えたのですが、見張り役が古い情報で「大丈夫」と言ってしまったら本末転倒なので、毎回取りに行くままにしました。数秒の待ちは、事故を防ぐための保険料だと思うことにしています。
3. 新しい Mac でセットアップを忘れる
別の Mac で新しく作業を始めたとき、この仕組みを仕込み忘れていても、反映自体は普通に動いてしまいます。これだと意味がないので、作業を始めるときのチェックリストに「ちゃんと仕込まれているかの確認」を入れておきました。できれば、環境ごとではなくリポジトリ側に手順として残しておくのが安心だと感じています。
「強制終了は最後の選択肢」
事故が一度起きると、「もう絶対に同じことが起きないようにしたい」という気持ちで、つい強い制限をかけたくなります。でも、強すぎる制限は、いざというときの逃げ道まで奪ってしまうんですよね。
そこで、方針は 「警告は強く、停止は最低限」 にしました。
- 手元が古いときと、保存し忘れの変更が残っているときは、思い切って止める
- それ以外は、内容を見てから進められるようにする
- どうしても通したいときの逃げ道も残しておく。ただし、逃げ道を使ったときはあとで必ず見直す
機械に守ってもらう部分と、人間が自分で判断できる余地と、両方を残したつもりです。
仕組みで守ると、頭が軽くなる
この仕組みを入れて一番うれしかったのは、「反映する前のチェックを、自分でずっと気にしていなくてよくなった」 ことです。
「最新を取り込み忘れていないか」「リモートの状態とズレていないか」を毎回頭で考えるのは、地味に脳の体力を使います。これを機械に肩代わりしてもらえると、本当にやりたかった作業のほうに集中できます。
個人でやっていると「自分自身が事故の元になる」場面が、案外たくさんあります。仕組みで守れるところは仕組みで守る、という方針を少しずつ増やしていくと、長く続けるのがずいぶん楽になる気がしています。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ