1. jenkins先生にライブラリの
更新をお願いする
- 天下一.gitconfig大会 -
2012/11/20
田中 裕一

2. 今日は
● 最近、継続的デリバリー本に洗
脳されました。
● git+github+jenkins+maven
でライブラリ更新が捗るネタやり
ます。
● .gitconfigは関係ないです。

3. ライブラリのアップデートやってる？
思い出したタイミングでやると結構溜まってきちゃっ
てアップデートの確認も大変です。

4. kintoneでは
● javaのライブラリはmavenで管理。
● 自社開発ライブラリも社内にnexusサーバー立て
て管理。
● 自社開発ライブラリは更新されたら、口頭でやり
取りして更新(でも忘れることもしばしば。。)
○ 常に追随しないとデプロイ失敗することも。。
● それ以外は、気が向いたら更新。大体数ヶ月に1
回の印象。

5. 頻繁にやった方が良いよね
じゃあ、普段からチェックする？
そんなのすぐに忘れちゃいます。

6. というわけで、
jenkins先生にお願いすることにしました。

7. 全体の仕組み
① 更新を確認
② 更新があればpom.xmlを更新
して、ブランチ切ってpush
③ ビルド
(テスト含む)
④ 作ったブランチのpull request
を作成
人間はpull requestを
確認するだけ！！

8. 各ステップでやること

9. ① pom.xmlの更新
maven versionsプラグインを使えば一発でpom.
xmlの更新までやってくれる。
http://mojo.codehaus.org/versions-maven-plugin/

10. ② ブランチを作成してpush
これは普通にjenkins先生がシェルで実行する。

11. ③ ビルド
以前より、githubにpushするとjenkins先生がビルド
実行する設定にしているのでここは割愛。

12. ④ pull requestの作成
github APIで一発 = curlコマンドで一発

13. demo
jenkinsを実行すると、こんな感じのpull requestを
作ってくれます。
テスト成功していれば、ボタンを押すだけでマージ
完了！

14. まとめ
● 普段から頻繁にライブラリをアップデートしてお
けば、差分が小さいから失敗しても原因の探求
が追いやすいはず。
● 変更をpushしたら都度テストを実行するのがキモ
○ これがなければ怖くて更新できない
● pull requestを勝手に作って作る所までは全
自動で最後の判断/修正は人間がやる。

15. 元ネタ
● 社内の継続的デリバリー勉強会での議論
● http://blog.kyanny.
me/entry/2012/11/06/003902

16. [追記] 当日のQ&A
● ビルドに失敗した時のワークフローは？
○ 失敗内容を確認して、kintoneに改修を入れる。
○ もしくは、あるライブラリに関してはもう今後アップデート
は行わないものとして、更新の対象から外す(versionsプ
ラグインのexcludesオプションで指定可能)。

17. [追記] 当日のQ&A
● 一度に複数のライブラリを更新するのではなく、
一度には一つしか更新しないようにはできな
い？
○ versionsプラグインではできないようなので、頻繁に確
認するしかないかも？