先日、デプロイツールを作成したという記事を投稿したが、第89回 PHP勉強会＠東京 でそれについての発表を行った。

当日の朝に自分が発表者になっていることに気づき、大急ぎで資料を準備して発表に臨んだ。
結果、資料の完成度の低さ、発表の段取りや分量など、かなり失敗して恥ずかしかったが、気付きもあったのでチャレンジしてよかった。
ちなみに、これは自分にとって初めての社外の人に向けた発表だった。

発表を通じてわかったこと

発表の時間配分

本題に入る前に時間が終わるというひどい体たらくだった。
今後、リハーサルはしっかりやろう、自分。

参加者のデプロイツール使用状況

参加者の方のデプロイ状況を知りたかったので、発表中に聞いてみた。

• デプロイツールを使っている人数
  20-30 / 60 人
  
• 内訳
  
  • capistrano 95 %
  • fabric 1人?
  • rocketeer 1人?

なんだかんだ capistrano 人気の根強さに驚いた。

質問

発表に対する質問も受けた。そのおかげで、デプロイに関してのポイントや自分が気づいていないところに気づけたので、質問者の方には感謝したい。

「既存のツールを使わないで、自分たちで作ったツールを使うメリットは？」

その時は上手く答えられなかったので、ここに書こうと思う。

メリットは、自分たちの仕事に最適化したツールが作れるということ。
既存のツールの不要な機能をそぎ落として、自分たちに必要な最低限のものを作れる。

デメリットは、しっかりメンテナンスをしなければならないこと。
スライド中にある、フロントツールのビルドに時間がかかるといった問題のように、時間の経過とともに出てくる問題に対処出来なければ使い続けていけるツールにならない。

また、既存のツールと違い、ネット上に情報が集積されていないので、作成者以外の人間が理解できるようドキュメントの整備は既存のツール以上にしっかりやらなければならない。

この辺りのことを考えると本当に一長一短で、 今後上手く行かなくなった時の選択肢として、 capistrano やその他の方法も考慮しておかなければと思っている。

「APC, OPcache を使用しているアプリケーションのデプロイは上手くいくか」

恥ずかしながら、APC, OPcache について知らなかった。
https://www.xserver.ne.jp/manual/man_server_php_apc.php
「APC」や「OPcache」とは、PHPの高速化、CPU負荷を軽減するための拡張モジュールです。
これらの拡張機能においては、PHPの初回実行時に、PHPの内容を最適化した状態でキャッシュしておき、次回以降、同じPHPにアクセスがあった際にキャッシュを利用することで、PHP実行時のCPU負荷の軽減や、PHPの大幅な高速化を図ることが可能です。

おそらくこの質問者の方が聞きたかったことに関連する記事もあった。
http://kohkimakimoto.hatenablog.com/entry/2014/09/13/154342
OPcacheはシンボリックを解決して、実ファイルパスの状態でキャッシュする。
よってシンボリックリンクを更新しても、実ファイルパスのキャッシュが保持されてしまう。

つまり、capistrano のようなシンボリックリンクを切り替えることでデプロイを実現しているツールでは、OPcache のキャッシュの影響で最新のファイルが実行・表示されないという問題があるらしい。
もちろん、上記ブログではその解決策も記されている。
こういった問題があることは全く知らなかったので勉強になった。

ryogoku に関して言えば、シンボリックリンクを張り替えず、実ファイルを上書きする作りになっているので、OPcache を使っていても問題にならない。

一方で考えたことは、OPcache を使うような高いパフォーマンスが求められるアプリケーションでは、シンボリックリンクを切り替えるタイプのゼロダウンタイムなデプロイが求められるのではないかということ。
そういったアプリケーションには ryogoku は不向きだと思った。

逆にどんなものが向いているか考えると、静的なコンテンツやブログ、CMSなど、コンマ何秒間のダウンタイムが問題にならないものかと思う。
言い換えれば、自分たちが普段仕事で開発しているアプリケーションがそういったもので、その範囲であれば ryogoku は十分なツールだと思っている。

「ロールバックはどうしている？」

ryogoku には revert というコマンドがあり、それでロールバックを実現している。
このコマンドの実際の動作がどうなっているかというと、戻りたいgit の commit id を指定してデプロイしている。
つまり、バックアップからの復元でない。
大抵はこれで上手くロールバックできるが、正直、上手くいかなかったこともある。

細かい話になるので簡単に言いたいが、あるデプロイを境に rsync の除外リストから外されたファイル(転送対象になったファイル)があると、ロールバックしたときに不要なファイルがデプロイ先サーバーに残ってしまうことがある。
これは今後改善しなくてはと思っている。

ちなみに capistrano であれば、デプロイごとにアプリケーションをまるまるディレクトリごと作成して、シンボリックリンクを張り替えて対応しているので、ロールバックも過去のディレクトリにリンクを張り替えればいいだけなので、確実。

ただ、ryogoku をシンボリックリンクを張り替えるつくりにはしたくないので、なにか考えないといけない。

発表を通じてわかったこと・まとめ

• 勉強会は補欠になっていても、繰り上がって発表者になることもあるので笑、準備はしておくこと
• 自作ツールは自分たちの仕事に合わせた細かい調整が利くが、メンテナンスやドキュメント整備を続ける責任がある
• ryogoku は静的なコンテンツやブログ、CMS といったコンマ何秒程度のダウンタイムを気にしなくていいアプリケーションのデプロイに向いている
• ryogoku のロールバックには改善の余地あり