Connehito/cake-sentryのメジャーバージョンupを(ほぼ)終えた

在籍中に作成・公開していたOSSがある。有り難いことに他薦を受けて awesome-cakephpにもリストしていただいたり、会社として初めて公開するソフトウェアだったりと、何となくの思い入れを感じている。

tech.connehito.com

既にコネヒトからは離れているが、元々の作成主であることと他にメンテナンスをしている人(コミッタ)がいないこともあり、現CTOに自ら願い出てその後もメンテナ権限をもらっている。今のところは。

めっちゃ遅くなりましたが!

今回は、Sentry側の提供しているSDKの大幅な変更が発生したため、それに伴うアップデート作業を行った。
この変更は当初よりずっと認識していて、また数日を置かずしてIssueも立てて頂いていたものだった。

github.com

これが2月なので、ここまで実に3四半期ほどを要したことになる。 やらねば・・・と思いながら、春夏を超え秋も終わるような時期になってしまった。
個人的な話としては、2-4月くらいはコレまでの社会人生活の中でもトップに入るくらい忙しくて(物理的にも精神的にも)他に何もやる気が起きず、5月からは転職活動をしたり、また5-10月の間にはコレもまたConnehito org下になるがOSSを2本出してみたり・・などして過ごしていた*1

その合間を縫ってチマチマと進めたりもしていたのだが、「作業が困難を極めた」というよりは「自分の中で、あまりテンションが上がらなかった」というのが十分に作業に取り組めなかった原因だなぁ・・とは思うところ。
上に書いたように確かに「春くらいから今に至るまで、色々あったよね」ではあるが、一時期を除いて「平日も休日も併せて数時間程度の余裕もない」という訳ではなかったはずなので、本来であればもっと早く出したかった。

主だった変更点など

Sentry SDKについて

Upgrade sentry sdk to 2x by o0h · Pull Request #17 · Connehito/cake-sentry · GitHub

主たるスコープというか動機としては、SentryのSDKバージョンアップ。
中身を見ると「すっごい変わってるなぁ」という印象をもたらすには十分な変更であり、コレが「気が重くなる」最大の要因だったようにも思う。

Version 2.x is a complete rewrite of the existing code base. The public API has been trimmed down to a minimum.

あるいは

It has a fundamentally different concept

と書いてあるとおり。
sentry-php/UPGRADE-2.0.md at master · getsentry/sentry-php · GitHub

ただし、開発者的な見方としては、やや"古臭く"なっていたコードベースが刷新されたことで、非常に触りやすくなったのではないかな・・?という風に感じている。
これで何が変わったのか?については、気が向いたら別途まとめてみたいが。

その一環は、例えばv1とv2の ClientTest を見てみると、コードがリデザインされて色々なレイヤーで関心の分離が行われてる・・・ような雰囲気から感じ取ることも出来るのではないだろうか。

2.2.0 sentry-php/ClientTest.php at 2.2.0 · getsentry/sentry-php · GitHub

1.x sentry-php/ClientTest.php at 1.x · getsentry/sentry-php · GitHub

とはいえ、プラグイン中で「実際にSentryのSDKに触れる」部分はLogクラスから使役されるClient だけだったので、その内部構造をいじることでそれ以外の箇所への影響はシャットアウトできる。これは、当初の設計として「CakeアプリケーションからSentryにどうやって触れるのが正解かな?」というのを丁寧に観察した結果だったな、と感じてホクホクしたポイント。
歴史的な経緯として、「かつて社内で使っていたSentryインテグレーションを、プラグイン化に際して構造からリライトした」ものであり、以前の状態だったら影響範囲をここまで閉じ込められていなかったかもなーとも思う。

CakePHPの新機能へのキャッチアップ

#5 Loading with Plugin objects by o0h · Pull Request #15 · Connehito/cake-sentry · GitHub

CakeSentry自体はコネヒト社内で利用されていたモジュールをプラグイン化したものであり、そのために機構としての歴史は多少古かった。
具体的に言えば、CakePHP3.5時代に「社内プラグイン化」したコードで、3.6からの機能であるPlugin Objectsに対応していない。

↓当該のPR
Implement Plugin Classes by burzum · Pull Request #11564 · cakephp/cakephp · GitHub

これを、今後の拡張性も見据えて対応させた。 SDKの大幅な変更の次に「気が重い」と感じていたのも、この「なんか凄そうな変更が入っているなぁ」と思っていた点。
結果的に、調べてみたらそこまで大げさな改修作業は必要ではなかったが。
まぁ、漠然と「どっかでやらないとな〜」と思っている事柄に対して「やらなきゃいけない新しいこと」が増えるのは、ネックにはなる。

test_appの追加

Add test app for supporting easy development by o0h · Pull Request #16 · Connehito/cake-sentry · GitHub

ここまではソフトウェアの機能としての「新しい変更点」だったが、これは「保守を簡単にするための追加点」となる。

改修作業に着手し難かった大きな要因として、「手元で簡単に動かせる状況になかった」ことが上げられる。
当然ながら自分のローカルに作業用の環境は用意していたのだが、 issue#10を貰った時には既に「久々すぎて、どう動かしていたか覚えてねぇ」状態だった。
これは思い出すまでが「遠い」し、何なら思い出しただけで「一仕事した、少し満足」となりがちなので困る!

ということで、docker-compose付きで test_app をレポジトリに突っ込んだ。
こうしたら、もうcloneしてからワンコマンドで直ぐに動かせるわけで、「どうやって動作確認しようか」というのは瞬殺で解決ですよ。

とりわけプラグイン単体だと「実際にどう動いてるの?」をイメージしづらい類のソフトでもあるので、簡単に目検でend-to-endな動作確認が出来るのは良いのでは、と思う。

CI周り

Improve ci by o0h · Pull Request #19 · Connehito/cake-sentry · GitHub

CI周りの改修も行った。
CakePHPの最新は現状では3.8だが、サポートバージョンを3.6+としている。
「3.6にある機能だけを使っている!」つもりではあるが、4.xに向けてのdeprecationも多く行われているので、「最新版を使った時にどう動くか」も継続的インテグレーションとして保証しておきたいな・・・という気持ちがあった。
というか、これはCIではなくて手動でやるのはキツい(退屈で複雑)。
ひとまず、「CIが緑になっていれば3.6+で動く」という安心材料になる状態に持ってこれたのは、今後の気安さを考える上でも良い材料になると思う。

この作業自体は、他のOSSに投げたdiffを参考にしながら比較的スムーズに出来たのかな?と思う。

ついでにphp7.4サポートを入れたり、phpstanのレベル強化&対象拡大等も行っている。

今後: 本リリースまでと、その後

testや環境構築系の確認、docs系の内容を見たり。またコード上の些細な整備やリファクタを行ってから、masterにマージして2.0.0-stableをリリースする予定。
作業的にもそこまで時間かかる内容ではないし、ここまで持ってきた以上は熱が冷めない内にやりきってしまう。
本当はCakeFestまでにはどうにか出したいなー、とは思っていたのだけど・・・・

残念なことに自分の係る環境でSentryをゴリゴリ使っているサービスがないので、十分にドッグフーディングが出来ていなそうな点が結構な心残り。
折角のOSSなので様々なフィードバックをいただければ・・とは願っているが、無責任なリリースを行うのとは全く別な話なので、心理的な引っ掛かりポイントだ。
何となくのイメージとして、2.0.3くらいまでは細かいサイクルで修正を重ねていけたら良いけどなぁと思う。もちろん、「品質的に何も問題なかった」という結果が得られたら、それが最もだが・・・・

それと併せつつやりたいこととしては、定期実行で「ちゃんとSentryのAPIを叩けているのか?」というE2Eテストを入れたいなぁという想いが暫く前からずっとある。
test_appを入れたのは、そういうところも見据えている。
実際のアプリ上で -> エラーを起こしてみて -> その後にSentryのAPI経由でデータを取得し -> 送ったつもりのデータがちゃんと受信されているかな?
という内容を、CI上で回せると良い。
これはTravisでもいいしGitHub Actionsでもいいかなーというところ。これを週1とか月1で実施して、動作性を保証できれば安心感が加速しそうなので・・・
また、今回のような大改修を入れる場合でも、「結果が正しい」というのをリアルに問うことができるようになるので、良さそう。Cake4公開までにやっちゃいたいかな〜

*1:とはいえ、公開された内の1つについては、暫く前から作業を進めていたものを大詰めした感じだけども