何が起きているのでしょうか?古いコードが実行され続ける原因OPcacheがキャッシュしているのはPHPのopcodeだけではありません。cacheの情報も一部OPcacheが管理する共有メモリ上に保存します。cacheの有効期限が切れた場合の挙動がphp-fpmとmod_phpで違うのです。cacheの情報を保持し続けます。実行され続けている」という状態を確認することが出来ます。php-fpm環境の場合古いキャッシュを保持し続ける事でシンボリックリンクを切り換えても古いコードが実行され続ける可能性があることがわかりました。cacheなのでそのキャッシュを適切にクリアする事が出来ればシンボリックリンクを張り替えた後のコードが実行できるはずです。OPcacheのキャッシュは「プロセスを再起動する」か「opcache_reset()関数を呼ぶ」ことでクリアすることが出来ます。cache共に消えるためダウンタイムの発生が許容出来るなら最も確実な方法です。opcache_reset()関数はどうでしょうか。実は、PHP7.0以降なら一定の解決策になりえます。cacheをクリアするので、不整合が発生することはありません。cacheにはノータッチでした。よって以下のような問題が引き起こされます。cacheがexpireされてからopcache_reset()関数を実行する」事になり、現実的ではありません。opcache_reset()を実行するまでは以前のコードが実行される可能性があり完全な解決策とは言えませんがロードバランサー切り換えほど大げさな仕組みを用意しづらい環境で、かつPHP7以降を使っているならopcache_reset()を使う事を考えても良いかもしれません。この方法だとopcache_reset()を叩くためのPHPコードを用意しなければならず、本番環境に適応する場合opcache_reset()を叩くためのPHPコードはローカルアクセスしか出来なくする、と一手間付け加える事が必要になります。そこで検討したいのが次の方法です。Webサーバにシンボリックリンクからrealpathへの解決を任せるnginxを使用している場合、nginxにrealpathの解決を任せる事が可能です。$realpath_root;に変更します。cacheによる問題は起こらなくなります。この方法ならopcache_reset()を使用する方法とは違い管理用のプログラムを別に用意することもないですし、アトミックなデプロイも完全な形で行えます。php-fpm環境では古いコードが実行され続ける事が確認出来ました。自分としては実行している環境がOPcacheの挙動に影響を与えるとは考えていなかったため、実際に挙動が変わる事が確認出来たのは面白い発見でした。opcache_reset()によってキャッシュをクリアすれば解決する、という記事も何件か見たのですがopcache_reset()はPHPのバージョンにより挙動が違いPHP7.0以降なら一定の解決策になり得ると言う事がわかったのも自分としては新しい発見でした。php-fpm環境ではOPcacheが原因で古いコードが実行され続ける可能性があることその環境でもnginxにrealpathの解決を任せたりPHP7.0以降のopcache_reset()関数を使えば便利さを損なわずデプロイツールの恩恵を得られることが伝われば幸いです。