継続的デリバリー座談会#3に参加してきました #cdelivery
継続的デリバリー座談会 #3 第3章 継続的インテグレーション についての座談会を楽しんで来ました。今回は、第3章 継続的インテグレーションの気になるトピックについて行われました。
- Togetter : http://togetter.com/li/343037
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
- 作者: David Farley,Jez Humble,和智右桂,高木正弘
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2012/03/14
- メディア: 大型本
- 購入: 22人 クリック: 451回
- この商品を含むブログ (31件) を見る
継続的デリバリー #3 ネタ帳
座談会で出たネタです。
3 継続的インテグレーション
この章、集中型のVCSを薦めているように感じる。3.8でDVCSに関する考察がある
3.1 導入
3.2 継続的インテグレーションを実現する
3.2.1 はじめる前に必要なもの
前提条件はプロジェクトが始まる前に用意できる、と考えている
- バージョン管理
- 自動ビルド
- .sln、.projectなどをコミットする?
- する2しない7
- .slnは1プロジェクト1slnの場合はコミット不要。
- チームの合意
- メンバーの意識?
- 大きなプロジェクトの場合は、教育コストが結構大きい
- 迷惑をかけているという意識が少ない?
- ビッグバンマージの怖さをしらない
- Subversionで手元が古いまま修正をしてコミット→ビルド壊れる
- 手元では動いているので問題意識が無い人がいる
- DVCSなら発生しない。
- つーか、バージョン管理、自動ビルドしていない会社あるの?IT舐めてるの?
3.2.2 基本的な継続的インテグレーションシステム
3.3 継続的インテグレーションの前提条件
3.3.1 定期的にチェックインせよ
- 2.2.2 と同じ話
- 定期的にtrunkにチェックインせよ→定期的にtrunkにマージせよ
3.3.2 包括的な自動テストスイートを作成せよ
- テストの用語集。赤は継続的デリバリーに登場する物
- ユニットテスト → メソッド、関数レベルのテスト
- ファンクショナルテスト
- コンポーネントテスト → クラス間テスト、ライブラリのテスト
- インテグレーションテスト → システム間結合(管理画面と表の画面)、外部システムとの結合
- システムテスト
- 受け入れテスト → シナリオベースのテスト。ブラックボックステスト。発注側がやるテスト?
- キャパシティテスト
- アイソレーションテスト
- http://jstqb.jp/dl/JSTQB-glossary.V2.1.J01.pdf
- フレームワークによって言葉が違う
3.3.3 ビルドプロセスとテストプロセスを短く保て
- FastTest, SlowTestを分離する
- TestNGのテストのグルーピング
- JUintのCagetories
- テストが遅いとテスト実行しなくなる
- 早くする工夫をしよう。
3.3.4 開発ワークスペースを管理する
- ソースコード管理しよう
- ライブラリの依存関係管理、Maven、Ivy(Ant、Groovy、Gradle)、nuget http://nuget.org/
- 定期的にバージョンアップした方がトータルで安く上がる
- お客さんにはメリットが見えにくいが。。。
- セキュリティfixはどうする?苦労してあげる?
- テスト実行環境を整える
- 開発環境に本番環境のソフトウェアをインストールする
- apache、memcached、mysql、rabbitmqとかとか
- IDEを使わない場合は本番環境と同じ環境を用意したVMで作業する
3.4 継続的インテグレーションソフトウェアを使用する
- みんな使ってる?
- Jenkins
- Bamboo(OSSなら無料?)
- Groovyの例 http://bamboo.ci.codehaus.org/browse/GROOVY
- Travis-CI
- buildbot
3.4.1 基本的な操作
3.4.2 オプション機能
- ビルドが失敗したら通知しましょう!
- Jenkins + 警子ちゃん
- im.kayac.comを使うと簡単にiphoneに通知出来るよ!
- 壊れたらすぐなおそう
- http://jenkins.turbogears.org/job/tg-2.2-py2.7/
3.5 基本的なプラクティス
3.5.1 ビルドが壊れている時にはチェックインするな
3.5.2 コミットする前に、常にローカルでコミットテストを実行せよ。あるいは代わりにCIサーバにやってもらえ
- プレコミットテスト
- パーソナルビルド
- プリフライトビルド
- テスト自動実行の話
- ruby
- https://github.com/guard/guard/
- https://github.com/sporkrb/spork/
3.5.3 次の作業を始める前に、コミットテストが通るまで待て
3.5.4 ビルドが壊れているのに、家に帰ってはならない
3.5.5 常に以前のリビジョンに戻す準備をしておくこと
3.5.6 リバートする前にタイムボックスを切って修正する
3.5.7 失敗したテストをコメントアウトするな
3.5.8 自分が変更してビルドが壊れたら、すべてに対して責任をとれ
3.5.9 テスト駆動開発
3.6 やったほうがいいプラクティス
3.6.1 エクストリームプログラミング(XP)の開発プラクティス
3.6.2 アーキテクチャ上の違反事項があった場合にビルドを失敗させる
3.6.3 テストが遅い場合にビルドを失敗させる
- jobを分離する方が良い気がする
- ビルドするjobが常にテストが遅いと失敗するのは辛い
- 強い動機付けは働くと思うけどね
3.6.4 警告やコードスタイルの違反があった時にビルドを失敗させる
- JDepend、NDepend、findbugs、checkstyle
- pep8?pyflakes
- rails_best_practices
- PMD、CPD、clone digger
- などなど
- ビルドを失敗させてしまうと、プロジェクトが進まなくなる。
- メンバーの練度にもよる
- ビルドを失敗させないまでも、統計を取っておくのは良いこと
https://docs.google.com/document/pub?id=19DiZVAgiYBJO4qxDW5BqZFkwfxSc-ZSTzPN2Me8L23I3.8 分散バージョン管理システム
- pull requestは少数のコミッターが必要
- これは真理だと思う
- マスターとパダワンが1人ずつ必要
- 無差別なインテグレーション
継続的インテグレーション入門 開発プロセスを自動化する47の作法
- 作者: ポール・M・デュバル,スティーブ・M・マティアス,アンドリュー・グローバー,大塚庸史,丸山大輔,岡本裕二,亀村圭助
- 出版社/メーカー: 日経BP社
- 発売日: 2009/08/06
- メディア: 単行本(ソフトカバー)
- 購入: 17人 クリック: 365回
- この商品を含むブログ (37件) を見る
継続的インテグレーションから始めましょう
どれかプラクティス1つということであれば、継続的インテグレーションをオススメする。CIを実現することで、構成管理、自動ビルド、自動テストに従わざるをえなくなる。チームによっては簡単ではないかもしれないが、インクリメンタルに実現でき、CIが基盤となり規律を守る #cdelivery
次回
2012/9/2(日)開催予定 とのことです。