に行ってきた話
内容的には、
- CIって何？
- jenkinsいいよー
- 商用CIツールの宣伝
CIの説明
ソフトウェアの調理方法を。
ビルドって何？ということで、そういやあまり考えたことがなかったな
ビルド自体はには２つの意味があることを。
- 実行可能なソフトウェアを作ること
- 実行可能なソフトウェア自体
「ビルドをビルドする」は
「料理を料理する」と同じ意味合いと言われてあぁって思った。
本題ですが
提供する側が必要なことってことで
「いつでも同じビルドを届けることができることが重要」
確かに、「あの時のビルドの環境作ってほしいんだけど」
ってよく言われるので、よく分かる。
背景を説明すると、リリースと開発が平行してて
リリースした製品でxxxなバグが出たから、再現環境作りたいんだけど
とか。
そんなときに、再現可能なビルドをしとくことが重要になると。
再現可能ってのはどういうことかというと
- いつでも誰でもビルドできる
- ユーザーに届けたものと同じものをビルドできる
これを実現するために
必要なことが、全部とはいわないが一般的に
- ソース
- レシピ
- 手順書
- スクリプト
- ビルドマシン
- コンパイラ
- ビルドツール各種
話は変わって開発環境の話ですが
開発者はサンドボックスでビルドすることが望ましい
じゃあビルドはどこでやるの？というと
ビルド専用マシンを立てましょう ということに。
んで、ビルドマシンが使うソースはどこに？ というと
リポジトリが必要でしょう。
- サンドボックス
- リポジトリ
- ビルドマシン
この３つを連携させて動作させると
「サンドボックス」で開発して
「リポジトリ」にコミットして
「ビルドマシン」がビルドする
これを繰り返していくことがCIですね。
キレイな環境で作ってあげることで
安定したビルドが出来上がると。
ただ実際に開発していくと、普通ソフトは壊れます。
実行時バグとか、他の機能に干渉するとか原因はいっぱいあるけど
壊すタイミングは何かってことになると
コミットしたときにビルドの成果物が壊れるんですね。
これを避けるための、コミットポリシー
大体コミットするときのお作法として決められているような内容ですが
- 自分のところでビルドしてエラーが無いことを確認する
- バディビルドを実施する
- コードレビュー
バディビルドをビルドサーバーにやらせるっていいなぁと思った。
実際にビルドサーバーがビルドするんだから、同じ環境で試しにビルドして
結果を教えてくれるなら、それが言いに決まってる。
まえに、名古屋のイケメンが話していた
自分用のブランチにコミットすると、ビルドサーバーがビルドしてくれて
OKなら、メインのリポジトリにコミットしてくれるっていう仕組みが
この流れと同じだと思うんだけど、環境構築大変そうだなぁと思ったり。
最後に、リリーストレインの話。
駆け込みコミットはお控えください
ビルドは定刻通りに発車しております。
これがすべてか。
変なタイミングのコミットは、本当に問題の元。
落ち着いて、良いリズムの開発を心がけたいものです。
まぁ一日一回のビルドだときついと思うので
デイリービルドするなら、プレビルド的な
コミットを監視してるやつも一緒に立てて上げるのがいいよなぁと思う。
jenkinsの話
なんでCIするのって話から。
インテグレーションを頻繁に行って、結合作業時に「え！？」ってならないように。
最近のCIの定義でいくと
ビルドを頻繁に行うことで、退行をできるだけ早く検出する
コードの品質検査を定期的に。
どっちにもいえることで
「機械ができることは機会にやらせればいいじゃない」
と。
僕も、ものすごくそう思います。
利点とか
リグレッションは、そのまま直訳で「後退、退化」なんですね。
うちの会社では、デグレとか読んでるソレです。
テストの場合は、前に出来たことが出来なくなることを見つけるので
リグレッションの方がしっくりくるかなぁとか思ったり。
リグレッションが早く見つかる
常にテストを書けている場合にかぎらず
成果物が常時できているので、コミットフックのビルドをかけるだけでも
結構違うと思う。
頻繁に成果物が生成されることで、ここからxxxの現象が出てるって
確認しやすくなります。
頻繁にリリースできるため、バグを早い段階で見つけることが出来
「あーそんな変更あったね（笑）」
を減らすことができます。
見える化
jenkinsさんは、情報収集が得意なので、各種情報が
jenkinsに集まり、ダッシュボードをみれば現在の状況
各種ビルドをみれば変更点やテスト状況など、みることができます。
属人制を減らす。
ビルドサーバーさえあればビルドできるはずなので
急にチームから人が消える
病気で倒れる
など、あったとしても大丈夫と。
あと、ビルドサーバーが開発のためのお手本環境になるので
各メンバーの開発環境を統一化するのにも一役かってると思います。
前に自分用Jenkinsいれた！って呟いたら、突っ込まれたのを思い出しますw
追跡可能性
バイナリが作られた原因（なんのコミット？）が分かる。
リグレッションの原因分析の手助けに使える。
かるくまとめ
CIは、手間を減らす というよりは
「人が人のやるべきことをやるために」
機械にできることは、できるだけ機械にやらせるのが良いと。
Jenkinsさんの紹介ですが
いいところをざっと。
- 導入設定が簡単
- 各種OSパッケージ
- プラグインによる拡張機能
- ４５０個以上のプラグインで多用な環境に
- プラグインを自作することもでき、さらに柔軟な環境へ
- FindBugs 静的解析かな？
- コードカバレッジの計算と表示
- チケットシステムとの連携
- 分散ビルド
って思ってたけど、jenkins自体がチケットに書き込みに行ったりするんですね。
プレテステドコミットとかは、難しそうだなぁって話してたら
かおるんに、TFSなら簡単に出来るよって言われたり。
流れてきには、
- 開発者が自分のトランクにコミットする
- jenkinsがそれを見つけて、ビルドとテスト
- OKならjenkinsからメインのリポジトリにコミットする
どの出来ることもそうだけど、機械には得意な事と不得意なことがあるので
得意なことはいっぱいやってもらって、あまったことだけ人間がやるのが
ベストだなぁと思います。
最後に、「具体的にはじめるには？」ってことで
- 千里の道も一歩から、
- ビルドの自動化
- テストの自動化
- コンポーネントを一つづつ
- 自動化の島をたくさん作って大陸へ進化
（苦手だ・・・）
最後の話は、未発表製品なので割愛。
静的解析ツールの話でした。
ディスカッションですが
全体的にまだ何もいれてない！ってところと
まぁそれなりに〜ってところが半々って感じだったのかな
（一番前に座ってたのであまり会場がみえなかった）
どの質問に関しても、共通して言えることは
Small start Small win
の繰り返し。
こんてぃにゅあす うぃん
です。
何事も、出来そうだなぁとおもったことをとりあえずやってみると
なんか見えると思います。
以上、勉強会レポでした。
勉強会後、
@heroweenさんとか、@shinyaa31さんとか、
@711fumiさんとか、@cyobichiさんとオムライス食べました。
いろんな話が出たけど、共通して言えることは
勉強会大好き と 開発者が楽しいって思えることを出来ないと
人は集まらないし離れていくってことでした。
さて、締めの言葉は、
「俺には前しかみえない（腹肉的な意味で）」
やっぱりこれですね。
ではでは。
0 件のコメント:
コメントを投稿