Dependency Update Bot

amatsuda, hsbt がRubyやRailsのバージョンアップやってると聞く。 それだけやっているわけじゃないんだろうけど、そんな職人芸を要求しないといけないことなのか? せめてその7割ぐらいを自動化(あるいは汎用化)出来ないか。 そうしたら、amatsuda, hsbtを雇えないスタートアップには百人力なのでは。 それならお金を払いたい(のではないか?)

7割の amatsuda bot, hsbt botを作りたい。 みんな、もっと本当にやるべきことがあるはずだ。 本人はそれはそれで楽しんでいるのかもしれないから(特に面識はないから知らない そのうち聞いてみたい)いいんだけど、なんだかなーってなってしまう。 RubyやRailsの特にコーナーケースを直すのは自分には荷が重いから、そこでテコが効いてるのならいいんだけど。

Bundle updateは楽しい。 最新の変更についていくのが容易になる。 簡単にコーナーケースでバグが踏める。 勉強になる。 でも、みんなが同じようにgithub探しに行って、diff見て…というのをやるべきだとは思わない。 作りたいものを作って欲しー Bundle update楽しい人が、楽しめる場を作ったら、もっとほかのみんなが楽しく出来るんじゃなかろうか。

PythonやPerlの人たちのところに聞きに行ったら、それほど下位互換バッキバキじゃない。 dependency hellになってないので、そこまで切実じゃない。 dependency hellにならないように依存ライブラリを厳選する、たとえばdjangoを使わない、など聞いた。

この資料: http://bit.ly/ZILpwC

The progress

9/17のtravis ci meetupのLTで公にお披露目。 9/18-9/20のはてなブックマーク効果、130 accounts。 hacker newsで+10, プラスアルファで現在2014-10-23 19:23 148。 1コでもリポジトリをactiveにしてくれた人 61。 ぼくの意図通りに使えてるようにみえる人 20。 private reposの有料アカウント 0。 2014-09-14 ~ 2014-10-22 で2483ユーザーなので、ランディングページもうちょっとわかりやすくしたらでだいぶ取りこぼしたかな。 pull requestから人が集まる妄想してたけど、今のところそんなことは起きてない。 1件だけ。しかも未対応のpython… Exec tachikoma update 20140918181203 by tachikomapocket Pull Request #172 kawazrepos/Kawaz3rd 甘くないなー 影響力のある人/プロダクトに使ってもらう(?) ちょっと博打的発想。 課金->使用ではなく、1mo無料->課金 にした方がいいかも。(小手先) 別のマネタイズ? テストやライブラリの統計・解析・分析など private reposの有料アカウントがそれなりに集まっても、人一人雇うのも厳しい。ゴールは? GitHub, Atlassian, Travis CI, Circle CI, ThoughtBot, あたりの1戦略に収まる程度? うーん

仮説

bundle updateで日々バージョンを上げていくことが大事だとわかっている企業/個人は、もう内部でその仕組を持っている(?) 必要だと思った人は内製してそう。e.g. Quipper などもとのtachikoma gem ユーザー。 Rails界隈以外はそんなにアップデートで死んでない。 この仕組に載せるまで、まず最新に追いつくところ、が職人芸なので、そこを何とかしたら良い?? しなければいけない? 定期的にクリーンな環境から何かを提供するaggregatorになる? travis-ci, circle ciのアドオン提供など?

現productの精度を高める

さらに補助productを作る

着地点?

趣味で継続, 一人が食べられる, ではなく大きくしたい 世界中で、当たり前に使われるサービスになりたい 言語的に仕組みとして取り込んでほしい ここは想像つかないけど、3年でGitHubに売却してGitHubberになる。 だとすると、チームか、ソリューションか、ユーザー数か、、、 その中で自分が何をしたいか、自分が事業のじゃまにならないか? はチョット困る

Service

Tachikoma.ioがしてくれること。 リポジトリのmaster branchに対して、何もせずに、定期的に、Pull Requestを送る。 すると、Travis CIのpass/failで差分に気付く。

One more thing...

おまけ 何もせずに、定期的に、Pull Requestを送る、と言いました。 各言語編 ruby: bundler, perl: carton, node.js: npm と言語ごとにパッケージマネージャーがある。 Gemfile, Gemfile.lock, cpanfile, cpanfile.snapshot, package.json, etc. と依存関係コントロールするためのメタファイル群がある。 これらは依存関係update hellだ。 これはもうこまめに定期的に最新安定版にアップデートしていく以外生き延びるすべはないのは確定的に明らか。 定期的に bundle update (ruby) / carton update (perl) / david update (node.js) やってますか? やってないでしょ? やってる? もっと簡単になるよ。 それTachikoma.ioで出来るよ。.tachikoma.ymlを置くだけでok。

.tachikoma.yml
strategy: bundler
strategy: carton
strategy: david
strategy: none (default)

定期的に bundle updateしてTachikoma.ioからpull requestが来る。 この場合、Travis CI のbuildログだけでなく、GitHubのcompare viewも頼りになる。 Tachikoma.ioのできることはTachikoma.ioに任せる。 あなたはあなたのやりたいことをやろう。

Summary

public repos版はFree! private repos版は月額有料です

This is service statement below

この下のはサービスステートメントです:

ライブラリの依存バージョンを上げないことは、すぐにはライブラリやアプリケーションにダメージを与えません。 新しく使いたいライブラリを追加するときに、既存のライブラリにセキュリティフィックスが出たときに、それぞれが正しく動作するバージョンの組み合わせを見つけることは、非常に困難です。 仮に組み合わせを見つけたとしても、すごく後ろ向きですし、次を追加するとき、より困難になって立ちはだかります。 また、ライブラリの新機能、スピードアップ、Ruby/Node.js/etc.のバージョンアップなどメリットを享受するために低いバージョンだとそれが使えないことがあります。 結果的に一番痛みが少ないのは、常に定期的に(安定した)最新版を組み合わせていくことです。 ここまでみんな知ってるしわかってるのに、なぜ出来ない?

それはツールやインテグレーションがまだ不足しているからだ、と私は考えます。 それを埋める1つのパーツがTachikoma.ioです。

Tachikoma.io

sanemat {AT} tachikoma.io