スライドが200枚を超え20分のトーク枠に収まらない予感がしましたが案の定収まりませんでした。誠に申し訳ございませんでした…… ちなみに社内で再演したところ30分かかりました。はい……
ということで話してきました。前半は割と教科書っぽいお話、後半がはてなの実験的サービスである大チェッカーでの実事例を紹介する、という中身でした。つまり大事な本題を話しそびれたことになりますね……
スライドはこちらです。多分これだけ見ても意味分からない。
後半の事例のうち、大チェッカー自体に関する部分については発表するはずだった内容をエントリ下部に記載しましたのでご確認ください。130枚目くらいからの中身に相当します（が、スライドの順序通りでない部分も多いです）。
処理系のバージョンアップはやったことがないとなにやら末恐ろしいことのように感じるかもしれませんが、（きちんとテストや検証体制がある前提で）バージョン差分が小さければ実際の所そんなに特別なことではないのだ……という認識のもと、サービスの寿命に合わせてヘルシーにバージョンを上げていけるとよいように思います。また、必要とされる変更を小さく切り分けて少しずつリリースしていくことで、バージョンアップそのもののリリースインパクトを小さくすることもヘルシーなバージョンアップ作業の大事な要素ですが、これはよくよく考えると継続的デリバリーにおける割と普遍的な考えではないでしょうか。
今回、B会場では Perl プロダクトの保守に関するいろいろな立場、話題のトークがあって大変興味深かったのですが、このトークもそんなトークの一つとして華を添えられていたなら何よりかなと思います。Hokkaido(Perl6 LT) => Kansai(Perl6 Talk) => Fukuoka(Perl5 Talk) と来たので次の Okinawa でも是非トークしたい。今度は時間に収まるトークをしたい！！！という気持ちであります。
補足
そういえば社内で再演したところ、「じゃあ具体的にはどうバージョンを上げたらいいんや」という話題になりました。個人的な所感としては、
- 5.x.0 はやや（安定性重視だと）蛮勇なので、 5.x.1 くらいまで待つ
- 最新の安定版で動作するところまで CPAN モジュールのバージョンは上げる
- アプリケーションコード自体は、コード内で使っている廃止機能が廃止ではなく警告で収まるギリギリのバージョンまでまず上げる
- 警告を見ながら廃止予定機能に対応していく
- 警告を潰せたら最新 or 1つ前の安定版まで上げる
くらいのフローがまあまあヘルシーではないかなと思いました。勿論様々な事情や条件によって変わってきそうですが。
