CI超入門:Jenkinsのススメに参加してきた #jenkins_night

豆ナイトでは、豆蔵と CloudBees,Inc. との教育提携を記念して 
「CI(継続的インテグレーション)超入門」を開催致します。 

「CIってどうなの?」「そもそもCIって何?」的な方をメインターゲットとし、
CIに興味はあるんだけど、導入はまだちょっと。。。というような方に向けて
その有用性やメリット及び考慮点等を、Jenkins(Hudson)作者である川口氏自身をはじめとして
業界トップエンジニアの口から語って頂くイベントです。 

この機会に是非、CIへの扉を開いてみませんか? 

先週末の連休で開催された『Jenkins温泉』に始まった"川口さん来日ツアー"におけるイベントの中の1つ、『CI超入門:Jenkinsのススメ』に参加してきました。

開催場所は株式会社 豆蔵 トレーニングルーム@西新宿。現場から大江戸線を使って都庁前迄来たのでそこまで混乱は無かったですが、JRではちょうど夕方のラッシュ時にアクシデントで運行止まると言ったトラブルがあったようで、今回の勉強会にも数人リア上が遅れた方も居りました。


1. はじめに

豆蔵関連のイベント及び今回の勉強会に関する諸連絡。関連する以下のURL情報が告知されました。

2. 「ビルドを料理するコツ (Cooking Ideas for builds)」

ソフトウェアのビルドに関する基本的な知識を導入します。
  • CI(Continuous Integration)とは…?
    • 継続してIntegration buildを構築し続ける
    • eXtreme Programingのプラクティスの1つ
    • 良い事を継続的に続けよう、という趣旨
  • CIの説明としては不正確?
    • XPよりずっと以前からあるもの。
  • Object solutionという書籍
    • 定期的なインテグレーションのプロセスが

Object Solutions: Managing the Object-Oriented Project (Addison-Wesley Object Technology Series)

Object Solutions: Managing the Object-Oriented Project (Addison-Wesley Object Technology Series)

  • Daily Builds and Smoke Test / Steve McConnel
    • "Daily Build and Smoke Test"
    • デイリービルドをプロジェクトの心拍とすべし。
    • 心拍のないプロジェクトは死んでいる。
  • Continuous Integration / Martin Fowler, 2000
    • Continuous Integration
    • このプラクティスはずっと以前からアリ、XP等使いそうもない多くの人々により使われてきた
  • Daily builds are your friends / Joel Spolsky, 2001
  • ビルドって何?
    • 1.実行可能なソフトウェアの事(名詞)
    • 2.実行可能なソフトウェアを構築すること(動詞)
      • ビルドをビルドする
      • 料理を料理する
    • 料理をビルドする
      • お料理をお客様にお届けするときに大切な事は?
        • おいしい料理をお届け
        • 品数の多い料理をお届け
        • 食べやすいお料理をお届け
        • バグが入ってないお料理をお届け
        • いつも同じお料理をお届け
    • 再現可能なビルド
      • いつダレガビルドしても同じ結果
      • ユーザにお届けしたものをあとで自社内で構築しなおせる
      • ビルドの再現可能性を確保する
    • 料理を再現するために必要なものは?
      • お料理の材料。
      • お料理のレシピ。
      • お料理の厨房と調理器具。
    • ビルドに置き換えると?
      • ビルドの材料
        • ソース
      • ビルドのレシピ
      • ビルドの厨房と調理器具
    • 清潔な厨房で料理する
      • 不衛生なサンドボックスでのビルドでは再現性を確保出来ない
      • 統合ビルドは、必ず清潔なビルドマシンで。
    • ビルドのレシピ
      • ソース/コンパイル/中間ファイル
      • 依存関係があり、正しい順序でビルドを行う必要がある。
      • 実際のビルドはかなり複雑。
      • ビルドのレシピ(全体)
        • インクリメンタルビルド
        • いろんなビルドのコンフィグレーションがあり、依存ファイルも異なる
    • 伝統的な調理器具:Make
      • 良い点:
        • 簡潔にファイル間の依存関係を記述出来る
      • 悪い点:
        • 方言がある
        • 複雑なことが苦手
        • 外部コマンドに依存する
        • ex) win では copy, Unixではcp等

    • Antの登場
      • James Duncan Davidson氏がTomcat専用のビルドツールをJavaで開発した
      • 分離、Ant1.1へ。
    • 近代的な厨房と調理器具の登場
      • 一昔前まで
        • 製品毎に固有のビルどシステムを構築していた
      • 現在
        • 汎用的で高機能なビルドシステムが利用可能になった
    • 材料の管理
      • 本質的には複雑で壊れやすいもの。
      • いつ壊れるか:コミット時に壊れる。
        • 誰かが変なコミットをして
        • SCMの頻繁なコミットはあまり…
        • リポジトリの中の一貫した構造を壊さないような仕組。

    • コミットポリシー
      • プライベートビルドをする
      • プライベートビルドをスモークテストする
      • バグ報告書を起票する
      • 単体テストを行う
      • コードレビューを依頼する
      • バディビルドもいっしょにお願いする
      • もう一度更新してプライベートビルドする
      • コミットメントを書く
    • リリーストレイン
      • リリース列車を定刻通りに発車させる
        • daily train, weekly train,
        • 今朝のデイリートレインが止まっているようだけど…
      • ビルドの日時(時刻表)を計画する
      • ビルドの開始時刻は厳守!
      • ビルドの成果物が複数あるなら、ビルド終了時刻を同期!
      • 駆け込み乗車をしない!
      • 機能を載せることが出来なければ、次のリリーストレインに載せる
  • まとめ
    • CIはプログラマの良きプラクティス(習慣)ではなく、開発プロセスの一部である
    • CIは、ソフトウェア開発プロジェクトが投資すべき対象である
    • 本を書いている。
      • みんなのソフトウェア開発(仮)
        • 2012/03発売予定
        • 2520円、A5, 256ページ
        • オーム出版

Jenkins本は今後2冊刊行予定ですが、こちらでも書籍が発売になるようですね。CI界熱いです。

3.CI超入門:Jenkinsのススメ

CIとは何か、Jenkinsで何ができるのかについて、初歩の初歩からお伝えします。 

本日のメインイベント的な講演。これまでJenkins勉強会で何度か講演を拝見していますが、今回はより初歩的・基礎的な部分に絞っての内容となっておりました。

  • CIとは?現代の答え
    • コンポーネントのビルド・テスト実行を自動化
      • 頻繁にコミットなどを行い、退行をすぐに検出。結合テストも含む
    • コードの品質検査の定期的な実行を自動化
      • テスト結果に表れない退行をすぐに検出
  • 利点:素早い退行の検出
    • Jenkinsは多くの計算機の効率的な制御が出来る
    • Jenkinsはテスト・検査の実行を忘れない
    • 退行が素早く出来ると…
      • リポジトリが安定し、一人の失敗が他人の作業を阻害しない
      • 退行の原因の切り分けが簡単に
      • 原因となった変更の事を忘れる前に検出しやすい
  • 利点:見える化
    • Jenkinsに情報が集まる
      • どのブランチがアクティブでどこに結合されているか
      • どうやってビルド・テストを実行しているか
      • 誰がコードの変更をしているか
      • 今どのテストが失敗しているか
      • 最新のバイナリは何で、それにはどの変更が含まれているか
    • 一箇所に集まっていると便利
  • 利点:属人性を減らす
    • 以前はこうした知識は特定個人の頭の中にあった
      • Jenkinsがあればその人が休暇を取っても大丈夫
    • チームに新しい人が来たときに便利
      • よそのチームに臨時に助っ人する場合も
  • 利点:追跡可能性
    • このバイナリはどこから来たの?
      • ブランチ、リビジョン、タグ等
      • どのテストが実行されたのか?結果は?
      • あるチケットにはこのバグ修正は含まれているのか?
    • 退行の原因分析の手助けに
    • 曖昧性を排除出来る。
  • 自動化が進んだ未来の希望図
    • より巨大なオートメーションを自動化し、人間にしか出来ない事に注力するように...

    • 世界インストール実績MAP
      • 様々な場所/様々な企業で利用されている。

  • Jenkinsの特徴
    • 導入・設定がとても簡単(java -jar -jenkins.war)
      • 各OS向けパッケージ
    • プラグインによる機能拡張

  • (デモ実演)
    • Svnリポジトリからソースを取得
    • ビルド
    • テスト実行
    • 各作業でエラーしたときの対応、等。
  • ビルドの自動化/テストの自動化が多い。でもそんなのはホンの入り口。
  • 出来る事(の一例)
    • FindBugsによる静的コード検査
    • コードカバレッジの計算と表示
    • チケット管理システムとの連携
      • コミットメッセージ等に表れるチケットIDを認識してリンクに
      • チケットにビルドの情報を追加
  • Jenkinsによる分散ビルド
    • 大規模な負荷に対応
    • マスター
      • httpリクエスト処理
      • 設定情報などの保存
    • スレーブ
      • 実行中に追加・削除などが出来る
      • 数百のスレーブの運用事例がある
  • テスト済みコミット:動機
    • トランクの品質を保つ
      • トランクに問題があると多くの開発者に影響が
      • 人間に不可避の間違いがトランクへ混入しないように
    • テストを非同期に走らせたい
      • 開発者は自分の変更に納得したら次の作業へ
    • テストをサーバで走らせたい
      • 手元の計算機をテスト実行で無駄にしない
  • テスト済みコミット:仕組み
    • 開発者は自分のブランチへのみコミット
    • Jenkinsがテストをしてトランクへマージ

  • 具体的に始めるには
    • 千里の道も一歩から
      • 1歩ずつメリットを享受しながら進む
    • ビルどの自動化
    • テストの自動化
      • 無かったら書こう
      • 全部自動化しなくてもいい
    • コンポーネントを1つずつ繰り返す
    • 自動化の島を組み合わせて大陸に

デモ実演については流れるような操作で簡単なプロジェクトにおける諸作業を行っておりました。

4.CIツールの紹介

製品紹介コーナー。1つは『Parasoft Virtualize』というものだったのですが、発売前の商品らしいのでここでは詳細は割愛(笑)

もう1つは『Coverity』という製品。詳細は以下の製品ページからどうぞ。

こちらの製品には川口さん(の所属する会社)も絡んでいたらしく、当日事情により来られなかった担当の方に替わり、簡単に製品紹介等をされていました。以下はその風景。(でも何故にちびまる子ちゃん…?ww)

5.ディスカッション

最後にディスカッションのコーナーが設けられ、今回登壇された講師の方々との質疑応答へ。印象に残ったもののみメモしてあります。その他の内容及び詳細はエントリ末尾のTogetterをご参照下さい。

  • 川口さんのコメント:
    • 自分が使っていると周りの同僚が、チームのみんなが使っていく
    • 導入は大きな障害。
    • マネージャーはその動き、力学を察知して動く事でメリットが得られる。
  • CIやってないひと:何が障害?

  • 自分の作業が楽になるなら、それでも良いのでは?
    • チームが乗って来ないのは残念でもある
    • 自分が嬉しい、という仕組み
    • チェックイン担当になる

  • 使ってるけど継続出来てない。次のステップは?
    • テストを書く。
    • テストを書かなくても実行出来るものを取り入れてみる。(findbugsとかもそう)
    • ビルドの他に退屈な提携作業等を自動化しても良い。(php ファイルの配置など)
    • 一番つまらないものから自動化。
  • テストを書くメリットを言えるかどうか
    • テスト=シートベルト、安心感。
    • 勇気を持って一歩踏み出せる。

  • テストで品質を作る事は出来ない。
    • テストは開発者がバグのないプログラムを作るためのもの
    • CIビルドとリリースビルドはきっちり分けよう。



タイトルに『超入門』とあるように、内容的には初心者向けのものでしたが改めてCIの重要性を認識する事が出来たイベントでした。

勉強会終了後には顔馴染みの参加者数名で新宿駅近辺でオムライスを食べながら軽く懇親。TwitterTL上でやり取りはあったもののリアルにお会い出来てなかった(ニアミスは幾つかあったが)risk(TwitterID:@riskrisk)さんとご対面。『青空プログラミング』のお話には驚きました…つかその状況は辛すぎます...(つДT)(笑)

そんな@riskriskさんのつぶやきから、最近色々な意味でビッグへの階段を着々と歩み続けているとあるお方が解散間際に発した『今宵の名言』を記念に載せておきます(笑)



今日を含めて3連戦→少し空けてScrum Gathering Tokyo絡みで3連戦に近いスケジュールと、またもやハードな日程になりつつあります。当然ながら通常業務も抱えつつなので、上手く時間を調整し、体力ペースも考えて乗り切っていこうと思います。(`・ω・´ )クワッ


その他関連URL: