kyobashi.dex #3で「Gradle PluginとCIと俺」の話をしてきた #kyobashidex

kyobashi.dex #3 で 「Gradle PluginとCIと俺」という話をしてきましたー。

rmp-quipper.connpass.com

主に最近仕事とかで新規にCI環境の構築をしたりして遊んでて、gradle-slack-pluginを使ったGradle Task + CI + Slackへの通知という仕組みを構築してみた!という話をしてきた。

ちなみに、今回発表した内容はGradleを使う開発ならAndroidじゃなくても仕組みは導入できる。

サーバサイドJava等でGradleを使っている場合でも適用可能だと思う。

Gradle PluginとCIと俺


文字起こしはGithubにも置いてあります。

github.com

資料内で紹介していることはだいたい以下のSample Projectにまとまってます。 仕組み自体はCIサービスといくつかのGradle Pluginを組み合わせる感じで実現しているので、Libraryみたいなさっくり導入できるものではありませんが難しくはないです!

めっちゃ雑ではありますがREADMEに同じ環境を構築するまでの手順をざっくり書いておきました。

github.com

gradle-slack-plugin + gradle-versions-plugin + CI

発表内でも紹介している中で特に「gradle-slack-plugin + gradle-versions-plugin + CI」という構成が気に入っている。

これで何ができるのかを簡単に言うと「CI上で使っているライブラリの新しいバージョンがあるかどうかをCheckして、その結果をSlackに通知する」って感じ。

以下のような感じでCI上で実行した結果がSlackに通知される。

f:id:operando:20160529122649p:plain

GithubにあげてるSample Projectを見ればわかるのだが、そんな難しいことはしてない。

Gradle Pluginの設定 + CIの設定 くらいの手順でだいたい構築できる。

自分はTravis CIを使ってるので設定方法はQiita等を調べれば色々見つかるし、Gradle Pluginの設定は使うやつのREADMEを見れはわかる。

Travis CIの設定がだるかったらsecret以外はSample Projectの.travis.ymlをパクってもいい。

これを発展させて、ライブラリを新しいバージョンへ上げるPull RequestなどをCIから自動的にできるようになるとさらに素晴らしいかも。

ちなみに、gradle-slack-pluginはoriginalを自分がforkして魔改造してるやつの方が使いやすいと思うのでオススメ!

github.com

可能性は無限大

結局これはgradle-slack-pluginの仕組みを使って、特定のGradle Taskの出力結果をSlackに通知しているだけの話なので、可能性は無限大だ。

例えば以下のようなこともできる。

色んなGradle PluginのTaskとgradle-slack-pluginを組み合わせるだけなので、構築も簡単、可能性は無限大!という素晴らしい世界だ。

誰かが素晴らしいGradle Pluginを作って、さらに素晴らしい構成を作ってくれることを期待してるし、自分も色んな構成で試行錯誤していく。

結局何が大事なのか

色々構成してCI上で行った結果を自分たちが日々チェックする環境へ通知してあげることはわりと簡単にできる。

その日々チェックするということだ大事だと思ってる。

CIと掛け合わせることで、日々チェックしたいことが自動で通知される仕組みが整うのでいい。

その結果を見て実際に何かをするかどうかは別として、自然な形で自動的に通知され、ふと思った時に確認できるということを大事にしたかったので、今回話したような構成を考えてみた。

まとめ

kyobashi.dexはいいぞ!