【ITニュース解説】A five-file Laravel release when the production worktree has drifted

今回のニュース記事は、ウェブサイトのデザイン更新を行う際、通常とは異なる特殊な状況下で、非常に厳密かつ安全なデプロイ（システムやプログラムを本番環境に導入すること）を実現した事例について解説する。

通常、ソフトウェアの開発ではGitのようなバージョン管理システムを使い、変更履歴を管理しながら新しいコードを本番環境にデプロイする。開発環境で作成した新しい機能やデザインは、Gitを通じて本番環境に反映され、古いコードは新しいコードで置き換えられる。しかし、今回のケースでは、本番環境のサーバーにあるファイルの状態が、Gitに記録されているはずの状態と「ずれていた」という問題があった。具体的には、ウェブサイトの見た目を定義するCSSファイルや、ページ構造を記述するBladeテンプレート（LaravelというフレームワークでHTMLを生成するファイル）が、開発環境の最新のGitブランチの状態とは異なるハッシュ値（ファイルの同一性を確認するためのデジタルな指紋のようなもの）を持っていたのだ。この「ずれ」がある状態で通常のGitデプロイを行うと、本番環境で意図せず変更されてしまったかもしれない重要なファイルまで、開発環境の古い内容で上書きされてしまうリスクがあった。

そこで、執筆者は、たった5つのファイル（CSSファイル1つとBladeテンプレート4つ）だけを、最大限の安全性と信頼性を持って更新するための特別なデプロイスクリプトを開発した。このスクリプトの中心にあるのは、「マニフェスト」という設計図のようなファイルだ。このマニフェストには、更新対象となる5つのファイルのパスと、それぞれの「変更前」と「変更後」のハッシュ値が厳密に記録される。

デプロイはまず、ローカルのリリーススクリプトから始まる。このスクリプトは、本番環境にファイルをアップロードする前に、まず本番環境の対象ファイルのハッシュ値がマニフェストに記載された「変更前」のハッシュ値と一致するかを厳しくチェックする。もし一致しなければ、デプロイは即座に中断され、ファイルはアップロードされない。これにより、本番環境が想定外の状態になっている場合に、誤ったデプロイが実行されるのを防ぐ。チェックがパスすると、変更する5つのファイルだけをまとめたtarという形式のアーカイブ（複数のファイルを一つにまとめたもの）と、マニフェストが本番環境のサーバーに送られる。

本番サーバー側では、さらに厳重な「適用（apply）」プロセスが実行される。このプロセスは「ファイルロック」という仕組みを使って、同じサーバーで複数のデプロイが同時に実行されないようにする。もし既にデプロイが進行中であれば、新しいデプロイはすぐに停止される。

適用プロセスには、実際にファイルを書き換える前に多数の厳格なチェック項目がある。 まず、以前のデプロイが失敗して残ったバックアップファイルなどがないかを確認する。もし残っていれば、リリースは中断される。 次に、本番環境のGitのコミット状態がマニフェストに記録されたものと一致するかを確認する。 そして、更新対象となる各ファイルの「現在の」ハッシュ値が、マニフェストに記載された「変更前」のハッシュ値と完全に一致するかを再度確認する。これは、ローカルでのチェック後、本番環境へのアップロード前に誰かがファイルを変更した可能性を排除するためだ。 送られてきたアーカイブ内のファイルが、マニフェストに記載されたものと一致しているか、不足がないか、そしてそれぞれのファイルのハッシュ値がマニフェストの「変更後」のハッシュ値と一致するかどうかも確認される。 PHPのコードファイルがあれば、基本的な構文エラーがないかどうかも自動的にチェックされる（Bladeテンプレートはスキップされる）。 さらに、ファイルパスに問題がないか、セキュリティ上のリスクにつながるシンボリックリンクなどが含まれていないかといった、パスの安全性も検証される。 これらすべてのチェックをパスした場合に限り、ようやくファイルの書き換えが許可される。

ファイルの書き換えは「アトミック書き込み」という非常に安全な方法で行われる。これは、直接元のファイルを上書きするのではなく、まず一時的なファイルに新しい内容を書き込み、完全に書き込みが終わってから、その一時ファイルを元のファイルの名前に変更するという仕組みだ。これにより、もし書き込み中にシステム障害が発生しても、元のファイルか新しいファイルのどちらかが常に存在し、中途半端に壊れたファイルがユーザーに見られることは絶対にない。さらに、各ファイルを書き換える直前にも、対象ファイルのハッシュ値を再度確認し、もしその瞬間に誰かがファイルを変更していたら、即座にエラーとして処理される。

5つのファイルの書き換えが完了すると、ウェブサイトの表示速度を最適化するためにLaravelのキャッシュ（config:cacheとview:cache）が再構築される。その後、再度すべての更新されたファイルのハッシュ値がマニフェストの「変更後」のハッシュ値と一致するかを最終確認する。このすべてのステップが問題なく完了して初めて、PHPアプリケーションを実行するPHP-FPMというプロセスをリロードするよう指示が出される。PHP-FPMのリロードは、PHPコードの変更が確実に反映され、古いキャッシュが使われないようにするために不可欠な工程だ。

万が一、適用プロセス中に何らかの問題が発生した場合は、自動的に「ロールバック」が実行される。ロールバックでは、事前に作成しておいたバックアップファイルを使って、元の状態にファイルを戻す。ここでも安全性への配慮は徹底されており、ロールバックを実行する際にも、対象ファイルの現在のハッシュ値が「変更前」または「変更後」のハッシュ値のいずれとも異なる場合（つまり、デプロイとは無関係に第三者が変更を加えていた場合）、ロールバックは中断される。これは、外部から行われた変更を誤って失わないための重要な保護措置である。

ファイルが正しく配置され、PHP-FPMがリロードされたとしても、実際にウェブサイトが正しく表示されるかは別の問題だ。そこで、デプロイの最終ステップとして、Playwrightというツールを使った自動ブラウザテストが実施される。このテストは、意図しない操作（フォーム送信など）が本番環境に影響を与えないよう、読み取り専用のチェックに限定される。具体的には、サイトの複数の公開ページを、デスクトップとモバイルの異なる画面サイズで訪問し、HTTP 200の正常応答が返ってくるか、ページにエラーがないか、主要な要素（見出し、画像など）が正しく表示されるか、さらにはモバイルメニューの開閉といったインタラクションが機能するかどうかまで細かく確認される。

しかし、これだけ厳重なデプロイでも、すべての問題が解決したわけではない。決済処理やメール配信といった重要な機能については今回のテストに含まれていない。また、本番環境のGitブランチは更新されていないため、次に通常のGitデプロイを行う際には、今回のデザイン変更が上書きされないよう注意が必要である。これは一時的な「技術的負債」として記録される。さらに、今回のハッシュチェックはファイルが意図した通りにディスクに存在することを証明するが、「そのファイルの内容が正しいか」という本質的な正しさは、ローカルテストやブラウザテストによって確認されるべきだ。ファイルの書き込みは個々のファイル単位ではアトミックだが、リリース全体としてはアトミックではないため、デプロイ中に新旧のファイルが一時的に混在する可能性がある点も考慮する必要がある。また、ファイルロックはデプロイを実行している特定のサーバー上でのみ有効であり、他のサーバーからの操作や、ロックを無視した手動でのファイル変更による競合のリスクは完全には排除できない。

この複雑なデプロイプロセスは、通常とは異なる特殊な本番環境の状況下で、たった5つのファイルの変更を、最大限の安全性と信頼性を確保しつつ実行するために設計された。これは、システムが複雑になるにつれてデプロイの難易度が高まる中で、あらゆるリスクを想定し、それを回避するための工夫が凝らされた事例だと言える。