CI（継続的インテグレーション）超入門：Jenkinsのススメに参加してきました！

こんにちは！おおはしりきたけです！

10月13日(水)に豆蔵さんで行われた豆ナイトのCI（継続的インテグレーション）超入門：Jenkinsのススメ」に参加してきました！

イベントURL：http://kokucheese.com/event/index/18660/

＝＝＝　アジェンダ　＝＝＝＝

１．はじめに

２．「ビルドを料理するコツ

３．「CI超入門：Jenkinsのススメ」

４．「CIツールの紹介」

５．「ディスカッション」

19時開始だったのですが、若干遅刻してしまったため、一部聞けませんでしたorz。

１．はじめに

豆蔵の羽生田栄一さんからのお話でしたが、遅刻のため聞けませんでした。

２．「ビルドを料理するコツ

ここの途中から参加したので、一部足りないです。

概要：ソフトウェアのビルドに関する基本的な知識を導入します。

発表者：Microsoft Office Linguistic Team. 津田義史 さん

■ビルドのコンフィグレーション

• 　32Bit、64Bit
• 　Unix、Windows

依存関係がある。

■伝統的な調理器具（Make)

良い点

• 簡潔にファイル間の依存関係を記述できる

悪い点

• 方言がある
• 複雑なことが苦手
• 外部コマンドに依存する（WindowsではCopy、UnixではCP）

Javaの登場

方言がないプログラミング言語

しかし、当時はJavaプログラムもMakeでビルド

なぜ？方言のあるツールでビルド？

Antの登場！！

当初は、Tomcat専用のビルドツールが開発された

■近代的な厨房と調理器具の登場

一昔前まで

• 製品ごとにまけなど組み合わせ固有のビルド

現在

• 汎用的で高機能なビルドシステムが利用可能になった。

■材料の管理

頻繁なコミットよりも、一貫したコミットをする

ソフトウェアは複雑で壊れやすい→誰が壊しているか？開発者

壊れたことに気が付かずコミットを繰り返していると修正しようがないくらい壊れている。。。

一貫したコミット？→コミットポリシー

■コミットポリシー

• プライベートビルドをする
• プライベートビルドをスモークテストする
• バグ報告表を起票する
• 単体テストをする
• コードレビューを依頼する→変更分をレビューしてもらう
• バディビルドも一緒にお願いする→バディ（相棒）にもプライベートビルド、スモークテストをする
• コミットコメントを書く

■自動化されたバディビルド

コードレビューをしたものを、以下の手順でコミット

1. コミットを依頼(ビルドサーバーに）
2. バディービルドとオートメーションの実行
3. コミット

■リリーストレイン

リリーストレインとは？⇒リリースを定刻通りに発車させる

• ビルドの日時(時刻表)を計画する
• ビルドの開始時刻は厳守！
• ビルドの成果ブルが複数あるなら、ビルドの終了時刻を同期！
• 駆け込み乗車をしない！
• 機能を乗せることができなければ、次のリリーストレインに載せる

■まとめ

• CIは、プログラマのよきプラクティス(習慣）ではなく、開発プロセスの一部
• CIはソフトウェア開発プロジェクトが投資すべき対象である

■お知らせ

「みんなのソフトウェア開発(仮)」が発売されます！

発行予定2012/3

３．「CI超入門：Jenkinsのススメ」

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

発表者：CloudBees, Inc. 川口耕介 さん

タイトル：「CI超入門　Jenkinsのすすめ」

Jenkinsの開発者の川口さんのお話です！

■継続的インテグレーション（CI)とは？

• インテグレーションを頻繁に行いnon-eventに
• 開発者は常にリポジトリの先端近くにいるように

これが提唱されたのは2000年

■CIとは？（現代）

コンポーネントのビルドテストを自動化

• 頻繁に(コミットごと）行い、退行をすぐに検出

コードの品質検査の定期的な実行を自動化

• テスト結果に表れない大綱をすぐに検出

■利点

Jenkinsは多くの計算機の効率的な制御ができる

Jenkinsはテスト・検査の実行を忘れない

退行が早く検出できると

• リポジトリより安定になり、一人の失敗が他人の作業を阻害しない
• 退行の切り分けが簡単に
• 原因となった変更の事を忘れる前に検出しやすい

■利点：見える化

Jenkinsに情報が集まる

• どのブランチがアクティブでどこに統合されているか
• どうやってビルド。テストを一考するか
• 誰がコードの変更をしているか

■利点：属人性を減らす

以前はこうした知識は特定個人の頭の中にあった

• jenkinsがあれば、その人が休暇を取っても大丈夫

チームに新しい人が来た時に便利

• よそのチームに臨時助っ人する場合も

■利点：追跡可能性

このバイナリはどこから来たのか？

• ブランチ、リビジョン番号、タグ等
• どのテストが実行されたのか？結果は？
• 金曜日にしたチケット1234のバグ修正は含まれているのか？
• 退行の原因分析の手助けに

■そこで、jenkins

Javaで書かれたOSSのCIサーバー

• http://jenkins-ci.org/
• かつてはHudsonと呼ばれていました。

世界でもシェア一位

日本語コミュニティの存在⇒日本語Q&Aがある

今は、NASAとかでも使われている

■Jenkins

導入・設定がとても簡単

• 各OS向けパッケージ
• java -jar jenkins.war

プラグインによる機能拡張

• 450個以上のプラグインによって多様な環境に対応！
• 大規模なところは、自作でプラグイン書いているところもある。

■デモ

jenkinsを使って、自動ビルド、自動テストのデモを行っていました。

■Jenkinsの使いどころ

FindBugsによる静的コード検査

• 開発者の1人1人がやるのは現実的ではないので、Jenkinsにやらせる。新しく発見される問題がJenkinsでわかる

コードカバレッジの計算と表示

• どの部分がテストされていて、どの部分がされていないのかJenkinsでわかる

チケット管理システムと連携

• コミットメッセージなどに表れるチケットIDを認識してリンクに

チケットにビルドの情報を追加

• クリックするとBTSへ
• マウスオーバーでチケットのタイトル

■Jenkinsによる分散ビルド

大規模な負荷に対応

マスター

• HTTPリクエスト処理
• 設定情報などを保存

スレーブ

• 実行中に追加・削除などができる
• 数百のスレーブの運用事例がある

■テスト済みコミット：同期

トランクの品質を保つ

• トランクに問題があると多くの開発者に影響が出る
• 人間に不可避の間違いがトランクに混入しないように

テストを非同期に走らせたい

• 開発者は自分の変更に納得したら次の作業へ

テストをサーバーで走らせたい

• 手元の計算機をテスト実行で無駄にしない

テストをしている間、PCの前に座っているだけというのは許されない！そのためCIサーバーに任せてしまう。

■テスト済みコミット：仕組み

• 開発者は自分のブランチへのみコミット
• jenkinsがテストをしてトランクへマージ

トランクにコミットできるのはJenkinsのみ

具体的に始めるには 千里の道も一歩から

• 一歩ずつメリットを享受しながら進む

ビルドの自動化

テストの自動化

• なかったら書く
• 全部自動化しなくていい

コンポーネント1つずつ繰り返す

○自動化の島を組み合わせて大陸に

４．「CIツールの紹介」

発表者：Parasoft Japan 株式会社　野田勝彦さん

タイトル：「エンタープライズシステムにおける継続的インテグレーションの実現性」

■継続的インテグレーション

ビジネスニーズに俊敏に対応するための実践的アプローチ

• 　　本当に実現可能なプラクティスか？
• 　　どんなシステムにも適用可能なプラクティスか？

■継続的インテグレーションの実践

構成管理

• 全てのソースコードのバージョンと構成が管理され、任意のバージョンをいつでも取り出せる

ビルド自動化

• ビルドプロセスが自動化され、コマンド1つでソースからシステムを作り出すことができる

テスト自動化

• テスト作業が自動化され、コマンドひとつでいつでもテストスイートを実行できる

リリース

• 最新の安定したビルドを、選別でき、入手できる

■テストの自動化

静的解析テスト

• パターン解析、コーディング規約
• フロー解析

単体テスト

• JUnitとかで自動化できる
• 結合テスト・機能テスト
• 負荷テスト・性能テスト

結合・機能テストの自動化の難しさ

• 機能性と見た目を同時にテストしようとする。
• 機能テストとコスメティックテストを分離する

機能テスト

• コマンドラインから全ての機能を起動敵るようなインターフェースをあらかじめ作りこむ

コスメティックテスト

• 人がやるのが最も効率が良い

■開発環境クラウド

システムテストはクラウド内で完結しない

• チームメンバーとのコラボレーションや設計～単体テストまでの作業はクラウド内で

社外システム

• 社外システムを利用したテストの場合、頻繁に、本格的なテストを実施することは困難

データベース

• 巨大で複雑な構造のデータベースを扱うアプリケーションをテストする場合、頻繁にテストを実施することは困難

メインフレームやERP

• メインフレームやERPは効果
• 一部システムは商用環境にしか存在しない

■ParasoftVitualize

• 　・エンタープライズシステムにおける系座奥的インテグレーション実践のためのプラットフォーム
• 　・新しいテスト環境・教育環境・構築・管理ソリューション
• 　・あらゆるシステムをエミュレーターで仮想化

仮想アセット

• 　・従来仮想化できなかったシステムもエミュレーターで仮想化
• 　・メインフレーム上で稼働するアプリケーション

注意点としては、仮想アセットを作りこみ過ぎない →作りこみすぎると膨大な工数がかかる

５．「ディスカッション」

最後に、申込時にあった質問を発表者の方とのディスカッションがありました。

■CI導入の文化がないが、どうしていくべきか？

津田さん

• できることから少しずつコツコツ
• 逆にCIの文化がないというのが不思議。それだけCIというのは重要なものになってきている

川口さん

• ボトムアップで使っているケースが多い
• 自分が使っていると、周りの同僚が使っていき、チームが使っていき、他チームへ広がっていくことが多い
• CIサーバーの導入が分散するのは労力の無駄なので、マネージャーはチームの中に怒っている力学の変化を早い段階でキャッチすること

■何がCI導入の問題になっているのか(津田さんから）

CI導入できていない方々から

• CI導入以前の問題でバージョン管理すらやっていない
• 過去の文化でリポジトリ管理をできないこともある(ソースに変更履歴を残すなど)

野田さん

• どんなソリューションを導入するにしてもバグ管理が一番最初⇒なぜバグが起きたのかをしっかりと管理する

川口さん

• SVN(中央管理)ができないのであれば、分散バージョン管理から始めてまずは一人で管理していくのも一つの方法

■CI導入にのってこない人がいて、草の根からなかなか進まない

野田さん

• 必ずしも全員がやる必要はない。まずは、自分が構成管理担当兼プログラマでやってみるなど

川口さん

• 自分の作業が楽になるようにすればいい。
• 仕事が増えるといいストーリーではなく、自分が楽になっているのを見せる

■CI入れているけど継続していない

ビルドは自動化しているが、テストコードを書いていない。

津田さん

• とにかくテストを書く、たくさんテストを書くとビルドを通すたびにエラーになる⇒やがてそれが快感になっていく
• CIビルドとテストビルドは分ける⇒品質の良いもの(テストビルド）をテストチームに受け渡す

川口さん

• 定番のパターンとしてはテストを書く
• CIが導入されているというのは、すばらしいことでテストを書く環境は整っている
• 退屈(定型的な)作業は、何かしらあるので、それをJenkinsにやらせる⇒静的チェックツールなど

野田さん

• なぜテストが必要なのかという問題意識が出ないとテストを書かない
• 私は、テストを自分でやるのが期待だからツールに任せている