業務で利用しているAWFの更新を、チームメンバーでローテで回しているのだがレポジトリの数が増えてくると大変だ。
私も先日、1つのレポジトリの更新作業担当になったことがあった。「手が空いたらやっておいてね」もしくは「スプリントの狭間くらいでやっておいてね」である。
恥ずかしながら機会を逃しているうちに数日が経ってしまい、むきーーー！というところでした。どちらかというと、普段は「更新しようぜ！！」と煽ち立てる役回りだったので立つ瀬がないという事はこの事。
転んだのにタダで立ち上がるのは癪なので、どうにか「CIで自動的にPR作るところまでやってくれ〜〜」という事をするようにした。
前提として、「こまめにupdateしていけると、修正対応とのコストは劇的に下がる(ほとんどのものは、互換性を保ったまま動いてくれることのほうが多い)」という立場です。
AWF本体の更新というのは大掛かりな部類と考えるが、それですら「ビルドバージョンごとに最新に追従していく」戦略をとることで、これまで大きな問題の発生を避けられているという体感がある*1。また、テストカバレッジも高めに保ててている〜という背景があるのに支えられていると感じる。
てな訳で、「更新しておいたわ！サマリーつけておくから、軽く確認しておいて！！」というPRをCIが自動的に出してくれ・・・という夢を、形にした次第です。
これは結局のところComposer Pluginという形に落ち着いたのだけど、当初はスタンドアロンに「Composerを使役する側」の何かを書こうとしていた。
- そもそもはyarnにはそういうのあるらしいよという話を聞いて、「composerでもできるっしょ！！」と思ったのがとっかかり
- お、gemにもあるじゃん
- どうやるかな〜composerコマンドをスクリプトで叩く感じかな〜
- まぁshでもgoでもいいよね〜
- updateしたあとにdiffをとって、内容をPRに書くのは必須だなー。
- hirakuさんのcomposer-diff-pluginは凄いわかりやすい、便利
- diffを取るのはcomposer使うとすぐできたりするかな・・？
- あー、じゃあPHPで書くかー
- どうやって差分取るんだ？composerソースコード読んでみるか・・
Commandクラス作ってinvokeしたりするのか〜- 結構大変そう・・・どうしたものか・・
- 今回のスコープはあくまで「CI上で動くようなもの」、なら「更新する」って仕事自体はCIに任せちゃっていいな。composer cli。
- そういえば、composer-diff-pluginがプラグインになっているってことは、「更新があったときに結果を受け取ってゴニョ」ができるってことだな
- なるほどcomposer-plugin、アリだな・・・！
という思考プロセス。
結果としてcomposer-pluginとか、普段からあんなにお世話になっているcomposer本体への興味が向いたのが凄く収穫に感じた。
何度も読んだスライド ↓↓
「いちおう動く」なところまでは行ったので、ひとまず(私が更新を忘れてしまって、かわいそうな・・)会社のレポジトリで試してみる。
テストとか静的解析を入れられていないので、書いた本人ですら「開発途中っていってもテストゼロってやばくない？糞ダサエンジニアじゃん・・・」ていう敗北感が強いのだけど。どうやってテスト入れたら良いのかなーーーーという感じ。*2
やれるところからやっちゃおう、という感じも勿論ありつつ。
そのあたりを形式だけでも整えてしまって、そしたらv1.0.0タグを打ってQiitaとかに使い方紹介記事みたいなの書こうかなーという算段
業務前とか業務後に時間を取ってやったので、それも毎日ではなかったということで、あまりまとまった時間を集中的に取る！！ということはできていなかったのだけど。
2週間前に思い立ち、2日めくらいに「そうか〜composer pluginなら行けそう！」と方針が変わり、最初の1週間で7割位のとこまで行って、実際にtravisのdaily cronで叩いたりして様子を見つつ、いまちょうど2週間目終わりかなって感じ。
1,2週間くらいでひとまず形になる〜〜〜ていう規模のペットプロジェクトは良いのでないかな、と思ったしリフレッシュになりそう
