When was the build passing?
その build passingはいつ?
If you use GitHub, you often see Travis CI's badge on README.
GitHubを使っていると、READMEにTravis CIのバッジが張ってあるのをよく見る。
Nice badge: build passing (Travis CI)
build passing(Travis CI), ナイスバッジですね。
However, when the build passing, it is not clear until you see other date parts.
ただ、いつのbuild passingなのかは、他のところを見ないとわからない。
authored on Jul 5, 2013 (captured on Sep 9, 2014)
"a year ago"!!!
I think if the build passed a year ago, then it will pass now, won't it?
一年前build passingだったら今もbuild passingじゃないの?
It is not assured!
そうとは限らない!
I want to solve this! This is the theme of my talk and my motivation to come here.
こういうのをどうにかするぞ! が話したいことで、話しに来たモチベーションです。
This paper is here http://bit.ly/travis-ci-meetup-tachikoma-io
この資料は http://bit.ly/travis-ci-meetup-tachikoma-io です。
sanemat - sanemat {AT} tachikoma.io
Travis CI Meetup 2014-09-17
When was the build failing? Actually 'Now'?
いつ落ちたの? ホントに「今」?
When I use Travis CI and GitHub, I meet this kind of story usually. No matter language I use.
Travis CIとGitHubを使っていると、プログラミング言語問わずよくある話だと思う。
I found out the failing test, which is library A's one that I want to use.
使いたいライブラリAのテストが落ちてるぞ。
I watched the result in Travis CI, and then I understood this.
Travis CI見て、どこが落ちてるかわかったぞ。
I searched this. After that I found out that API requires 'ac' params, this is the problem.
ちょっと調べて、これがAPIの必須パラメーターが足りなくなっていることが原因だとわかった。
Thus, I fixed failing test!
テスト落ちてるの直したぞ。
And finally sent a pull request, but...
プルリクエストを送って、あれ?
WOOOOOO! Fail, Fail, Fail and Fail!
うわぁぁぁぁ。 Fail, Fail, Fail and Fail!
This is about the library A's component library dependencies.
これはライブラリAの依存するライブラリの話。
We didn't fix the dependency version, this is one of the causes.
依存バージョンを固定していなかったことが原因の一つではある。
It is not a story that, we would have to fix the dependency version.
ただし、依存バージョンを固定してればよかった、という話では ない 。
This library A depends on another library B, and A hits B's bug.
このライブラリAが依存するライブラリBのバグを踏んでいた。
Hence, We should update B's version.
なので、依存するライブラリBのバージョンはどうしても上げる必要があった。
We can update v0.1.2 to v0.1.3 easily.
バージョンひとつ上げるならよかった。
Now B's version is v1.2.3, oh. v1 requires bump node.js version.
だけど、その依存ライブラリBを最新版にするにはnode.jsのバージョンを上げる必要があった。
Bump node.js version break A's another dependency library C,
node.jsのバージョンを上げると、別の依存ライブラリCが壊れるので、
(snip)
以下略
Great news, The build failing is not happening now !
壊れたのは 今 じゃない
Too many tests fail on now pull request. It is difficult to find out where I should fix.
今 のpull requestではテストが盛大に落ちる、場所の特定も面倒だ。
If I'm at my first failing build, then I can find out this easily, and fix it easily too.
もしこれが、はじめのfailの段階なら、場所を特定するのも簡単。直すのも簡単だった。
I'm sick of this!
こういうの、うんざりだ! よくある!
This talk so far is when you use the libraries which other people made.
ここまでの話は他人のライブラリを使う時の話。
It is the same thing when you provide the library/application.
おなじことは自分が、ライブラリの提供側・アプリの提供側の時も言える。
First of all, I change the provider side!
まずは、提供側から何とかするぞ!
I made Tachikoma.io, this is an awesome application.
神webアプリつくった Tachikoma.io
Interval Pull Request
定期的な Pull Request
What are the pros doing that?
何がいいか?
Differences between rebuild via Travis CI API
Travis CIのAPIで、rebuildするのとの違い
When start fails, we can visually see logs from Travis CI and GitHub.
いつから落ちたか視覚的にTravis CIとGitHubでわかる。
The best thing is relax version dependencies. semver...
ゆるめのバージョン指定が一番良い。semver...
We can see the build log at Travis CI.
Travis CIでビルドログを見るとわかる。
Leave it to Travis CI is that you can Travis CI.
Travis CIのできることはTravis CIに任せる。
Leave it to Tachikoma.io is that you can Tachikoma.io.
Tachikoma.ioのできることはTachikoma.ioに任せる。
You should do what you want to precisely do.
あなたはあなたのやりたいことをやろう。
Dependency update is not what you want to do! What you want to do is writing application!
だって依存のアップデートがあなたのやりたいことじゃないでしょう? アプリケーション書きたいでしょ!
We use Travis CI in combination with Tachikoma.io!
Tachikoma.io と組み合わせて使うのは, Travis CI!
This is not a bad app?
なかなかいいアプリでしょう?
One more time.
もう一回。
What Tachikoma.io does.
Tachikoma.ioがしてくれること。
This sends interval pull request to the repository's master branch with nothing.
リポジトリのmaster branchに対して、何もせずに、定期的に、Pull Requestを送る。
Then you can find diff from the result of pass/fail at Travis CI.
すると、Travis CIのpass/failで差分に気付く。
(Maybe 4minutes?)
(4分ぐらい?)
You boast your product, Tachikoma.io?
自分のプロダクト Tachikoma.io の自慢?
Yes!
はい!
One more thing...
おまけ
I said 'This send interval pull request with nothing'. Nothing!
何もせずに、定期的に、Pull Requestを送る、と言いました。
In specific language:
各言語編
ruby: bundler, perl: carton, node.js: npm, each langualge has its own package manager library.
ruby: bundler, perl: carton, node.js: npm と言語ごとにパッケージマネージャーがある。
Gemfile, Gemfile.lock, cpanfile, cpanfile.snapshot, package.json, etc. There are meta files for control dependencies.
Gemfile, Gemfile.lock, cpanfile, cpanfile.snapshot, package.json, etc. と依存関係コントロールするためのメタファイル群がある。
This is Dependency Hell.
これらは依存関係update hellだ。
This is obvious that the only way to survive is updating them to the latest stable frequently.
これはもうこまめに定期的に最新安定版にアップデートしていく以外生き延びるすべはないのは確定的に明らか。
Interval bundle update(ruby)/ carton update(perl) / david update(node.js)
定期的に bundle update (ruby) / carton update (perl) / david update (node.js)
.tachikoma.yml
strategy: bundler
strategy: carton
strategy: david
strategy: none (default)Do you do this? I think you don't do, do you? "Yes I do", you says, you can do this more easily.
やってますか? やってないでしょ? やってる? もっと簡単になるよ。
You can do it with Tachikoma.io. The only thing that you should do is putting .tachikoma.yml.
それTachikoma.ioで出来るよ。.tachikoma.ymlを置くだけでok。
Interval bundle update and send a pull request from Tachikoma.io.
定期的に bundle updateしてTachikoma.ioからpull requestが来る。
In this case, not only Travic CI builds log, but also the GitHub compare view.
この場合、Travis CI のbuildログだけでなく、GitHubのcompare viewも頼りになる。
Leave it to Travis CI is that you can Travis CI.
Travis CIのできることはTravis CIに任せる。
Leave it to Tachikoma.io is that you can Tachikoma.io.
Tachikoma.ioのできることはTachikoma.ioに任せる。
You should do what you want to do.
あなたはあなたのやりたいことをやろう。
We use Travis CI in combination with Tachikoma.io!!
Tachikoma.io と組み合わせて使うのは, Travis CI!!
Summary
まとめ
Use Tachikoma.io.
Tachikoma.io 使って。
Free for public repositories.
public repos版はFree!
Subscription for private repositories.
private repos版は月額有料です
- for private individual $9/mo
$19 - for private organization $49/mo
- for enterprise
- email: sanemat {AT} tachikoma.io
More ideas
さらにアイデアベース
- Show the build log like Travis CI
ビルドログ見えるようにしよう Travis CIみたいに
- Notify a build completion (and not completion)
ビルド終わったら(終わらなかったら)notification 飛ばしたい
- Make a badge :)
badge作りたい
We use Travis CI in combination with Tachikoma.io!!!
Tachikoma.ioと組み合わせて使うのは, Travis CI!!!
This is service statement below
この下のはサービスステートメントです:
Not updating the dependent libraries, does not damage the library/application immediately. When adding a new library that you want to use, occurring a security issue in a library which is already in use, it is extremely difficult to find the right version that functions properly with it. Even if you find the right combination, it's very reactionary and it even gets harder when adding the next one. Furthermore, sometimes with an older version, you won't be able to enjoy new library features, increase in speed, updated version of Ruby/Node.js/etc., and other benefits. Ultimately, choosing the latest(stable) combination periodically will keep damages to a minimum. Everyone knows this, so what's stopping them?
I believe it's due to the lack of tools and integrations. That is where Tachikoma.io comes in.
ライブラリの依存バージョンを上げないことは、すぐにはライブラリやアプリケーションにダメージを与えません。 新しく使いたいライブラリを追加するときに、既存のライブラリにセキュリティフィックスが出たときに、それぞれが正しく動作するバージョンの組み合わせを見つけることは、非常に困難です。 仮に組み合わせを見つけたとしても、すごく後ろ向きですし、次を追加するとき、より困難になって立ちはだかります。 また、ライブラリの新機能、スピードアップ、Ruby/Node.js/etc.のバージョンアップなどメリットを享受するために低いバージョンだとそれが使えないことがあります。 結果的に一番痛みが少ないのは、常に定期的に(安定した)最新版を組み合わせていくことです。 ここまでみんな知ってるしわかってるのに、なぜ出来ない?
それはツールやインテグレーションがまだ不足しているからだ、と私は考えます。 それを埋める1つのパーツがTachikoma.ioです。
We ship to the world!
世界に羽ばたくのでよろしくお願いいたします。
sanemat {AT} tachikoma.io