kuroneko's blog

とりとめもなく気づいたことを書いていく

Jenkinsユーザ・カンファレンス2012 に参加してきました(その2)

この前のロンドン五輪テニス準々決勝の錦織圭選手、負けてしまいましたが強くなったなぁ、と思いました。タイトルを取るには壁が厚すぎる今日ですが、これからも頑張ってほしいです。

 

 

で、前回の続きです。

 

3.Jenkinsを活用する方法について

ここでも英語が。。。ですが、スピーカーの人の英語はすごいわかりやすい言葉?でしゃべってくれているみたいで、なんとなくわかる範囲でした。

 Git+Gerritによってコードレビューをトラックする、という考えが一番印象に残りました。コードレビューして、ダメだったらRejectして、OKなら承認してupstreamに上げる、という仕組みがうまく回れば、Git+Gerritの仕組みの中に、全てが残ることになりかつ、承認したものしかupstreamに残らないことにもなる。いちいち別のところに見に行く必要はないし、統一的に管理することができるなぁ、と思いました。

 コメントにナイスとか、いいね!みたいな文章がさらっと入っているあたりがいい雰囲気だと感じた。本来コーディングって楽しくあるべきだろ?という思想?が見えて非常にいいね!と感じた。

 

4.開発者とディレクターの視点を変えていく方法

 あるべき論、精神論ではなく、ワークフローとして取り込んでしまうことで、混乱やリリースの手間を効果的に削減する、という取り組みに関しての講演でした。

 あるべき論をする人って、非常に多いんですが、そこからの議論がないので、各自気をつけること、ってあたりで終わってしまい、結局なにも進展がない、ということがよくあります。今回の例でいくと、

  • デザイナーが周りに気を使ってコメントを躊躇する

  →(ありがちな解決策?)時間と相手の忙しさを考慮して積極的にコメントする

    →これじゃ、何も解決になっていないし、個人の努力で補えるもの??

  • エンジニアによって逐次バグ改修を行なっているが、レビューワーがコメントするバージョンが各自異なる

   →(ありがちな解決策?)ファイル名を間違わないようにルールを制定する

    →これをやっても結局誤ったわけで、今回の例では意味がない

  →(ありがちな解決策?)エンジニアはバージョンアップしたら、レビューワーが

    間違わないような周知メールを送る

    →手間が増える割に、メールの見落としはありうるわけで、根本解決になっていない。。

などなど、自分の配慮が足りなかったから次は気をつける努力をする、という方向に行きやすいと思う。けど、そういった解決法って結局また繰り返すと思う。その点、Jenkinsをうまく使って問題を解決しているな、と感心しました。妥協点を見出して制度化する、という「妥協点」というところも工夫しており、うまく現場にカスタマイズしているな、と思いました。

 

5.LT

書籍の作成?などにJenkinsを利用している、というのが印象に残りました。Jenkins自体は、コーディングにしか使えないわけでなく、漠然と言うと

 ・要求に対して自動化された仕事を実施する

 ・仕事の結果を管理し教えてくれる

ということなのかなと思います。おじさんが肩代わりしてくれる仕事はなんでもよいのです。バックアップでもよい。その結果を残し、周知してくれるわけで、その用途は広いな、と感じました。

 

 

 6.最後に

 全体的に、非常に勉強になり(スポンサー枠で一部宣伝オンリーっぽいところがあって、微妙なところもありましたが)、カンファレンスに参加して、自分のモチベーションが上がってよかったです。SVN同様、開発等に必須のソフト、という感じがしました。

 スピーカーの方々、スタッフの方々、お疲れ様でした。