アジャイルサムライ読書会 新宿道場#8 に参加してきた #agilesamurai #新宿道場

勉強会 読書会 Agile


(写真：懇親会、KPT振り返りでの一幕。)

第8回目は第V部の最終章である第15章継続的デリバリーをテーマにすすめます。
今回はSpecialゲストとして、分散バージョン管理システム Mercurial のエバンジェリストである
@troterさんをお迎えしての講演、@tk0miyaさん司会の座談会、LT大会等を計画中です！

LT参加者も合わせて募集しますので、話をしてみたい人は是非声をかけてくださいね
(アジャイルサムライに記載の内容と関連する事であれば第15章以外であってもOKです)。
初LTデビューも大歓迎です！

前回参加していなくとも参加できますので、気軽に参加してくださいね。
アットホームで和やかな雰囲気なので、初めての参加でも大丈夫ですよ:-)

新宿道場は今回で第8回を数え、読書対象範囲も第15章と終盤を迎えた状況ではありますが、継続的デリバリーに関するテーマで@troterさんが講演されるというのにも非常に興味があり、(新宿道場)初参戦してきました。

会場は株式会社タイムインタ―メディア＠曙橋。事前に別件で参加者数名の方々と打ち合わせをしていたので、その流れで(新宿道場)常連参加者の方々についていって到着。

オープニング

本編

タイムスケジュール進行について参加者を含めた調整協議の後、以下の順番で進行することに。

  • 講演会
  • 座談会
  • LT大会

講演：継続的インテグレーションって実際どう導入するの

  • 今日の話
    • 継続的てどう導入するの？
    • 導入した経験を元に実際の導入方法について話そうと思います。
    • 導入したい人向けなので、利点の話とかはあまりしない。
開発者がソフトウェアに加えた変更を取り込んで、ソフトウェア全体として統合する作業を途切れなく続けていく取り組みの事
    • ツールではなく、プラクティスの事。
  • コミットするたびに結合。
    • コミット
    • チェックアウト・クローン
    • ビルド
    • テスト
    • インスペクション
    • 開発者を交え、フィードバックを得て行くサイクル
  • 一連の流れの作業について、何を利用しても良い
  • 理想と現実の埋め方
    • 導入するためにはどうすればよい？
    • ...でも、本当にこれだけ？
  • 僕が考える導入手順
    • 順番にみていきましょう。
  • まずは説得が大事
    • 何をするにも味方の存在が重要
    • 見込みのある同僚を確保し、次の本を与えよう

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

    • 出来れば上司とも掛け合い、同僚や上司にCIサーバ用マシンを用意してもらえるよう頑張って。
  • CIマシンの確保
    • 型落ちのPCやVMで問題ない、
    • プロジェクトごとに必要なスペックは違うが、目安にすればいいだろう。
      • CPU/その時のもの
      • メモリ/1.5G
      • 容量30GB
    • とろたーさん自身、仮想環境を使うことが多い。
    • EC2とか使う場合は毎晩落としている。
  • CIマシンの注意点
    • ビルドとテストの実行に必要なソフトウェアをすべてインストールする必要がある。
    • .NETの場合とか、結構掛かる。
    • ライセンスの確保頑張ってください。
    • テスト実行する都合上、デプロイするマシンと(OSレベルで)同じ構成にするのが好ましい。
    • インストールするソフトウェアもデプロイ環境に合わせること。
  • CIサーバ構築のための時間の確保
    • VCSの用意
    • ビルド自動化
    • ユニットテストの自動化
    • 0から構築する場合、ビルドツールの調査を含め2週間程の作業が必要だと考えて下さい。
    • まずビルドできる事が大事。
  • VCSの用意
    • まともな会社だったら次のVCSを使っていると思います。まともな会社だったらね…
  • IDEとの関係(Java編)
    • IDEの設定ファイルはビルドツールから生成することをおすすめします。
    • この場合、既存のプロジェクトをワークスペースにインポートすることになる。
    • maven+eclipseの場合
    • その他の場合(ちょっと例が古いけど)
    • 開発環境、ビルドを共通化出来る。
  • IDEとの関係（.NET編)
    • ソリューションファイルをコミットする。
    • MSBUilDはソリューションファイエウを読み込んでビルドを実行する

  • ユニットテストの自動化
    • ビルド自動化で使ったビルドツールやユニットテストツール付属のテストランナーで自動化。
    • ビルド自動化が行えればテスト自動化は比較的カンタン。（テストが通るかどうかは別の話）
  • Jenkinsのプラグイン
    • ジョブを作成する前にプラグインをインストール。
    • 最低限、次をインストール。
      • VCS系
      • ビルドツール系
  • ジョブの作成
    • Javaの場合はmaven2/3スタイル
    • それ以外はフリースタイル

  • ジョブの作成2
    • 必ず次のことを実現。
    • ビルドのジョブとビルド＋ユニットテストのジョブを分離させてもいいと思います。
    • これでCIサーバが構築出来ました。
  • メンバーの教育
    • VCSを変更する場合は説明会を開催する。
    • 最近だとscmbcの資料があるのでそれを利用するのが良い。
    • ハンズオンの開催も効果的。みんなで覚えようとするのが大事。
  • VCSの効果的な使い方
    • 1.一度に１つの変更を行う
      • 問題の箇所がすぐわかる
    • 2.コミット前、プッシュ前にテストを動かす
      • ソースツリーを壊さない、迷惑をかけない
    • 3.DVCSの場合は）履歴改変方法を覚える
      • 変更点をより論理単位に出来る
      • 必須ではないがだんだん必須になってくる
  • テストの書き方
    • 書き方を共有する。
      • モデルのテスト
      • コントローラのテスト
      • ビュー・テンプレート
      • モックの作り方
      • DBと結合する場合
      • フィクスチャ・テストデータの管理
  • テストの書き方の注意点
    • いきなり完璧を目指すと挫折する。
    • スモークテストでよい。とにかくテストを書くことを目的にしよう。
    • テストがあればCIさーばが勝手に実行してくれる。
      • 1.正常フローの動作を確認するスモークテスト
        • テンプレートが表示される、modelがnew出来る、等
      • 2.モデル。コントローラの単体テスト
        • バリデート、パラメータのテスト
      • 3.モデル、コントロラー間の結合テスト
  • よくある質問
    • [Q].CIサーバの構築はいつやるべき？
      • イテレーションゼロで完了させるべき。
      • スケジュールに構築作業を組み込むのが良い。
      • スケジュールに組み込めない場合は業務時間外にやるしかない。
      • アジャイルサムライ P195
    • [Q].途中から導入したい時は？
      • 上司、お客さんを説得してCIサーバ構築の為の作業をスケジュールに組み込む、。
    • [Q].初めてCIサーバを構築するのですが不安です。時間も掛かります。
      • 練習するしか無い。自分で学ばない限り、出来るようにはならない。
      • Jenkinsならダウンロード含め1時間で立つよ。
    • [Q].対象言語のビルドツールに習熟していないのですが...
      • ggrks 習熟するしか無い。
      • CIは種々の知識が無いと何も出来ない。
      • 頑張ってください。
      • ビルド職人が居るのはまだ幸せなプロジェクト
      • やはり、この辺りの習熟コストは高い。
    • [Q].どんなプロジェクトでも導入すべき？
      • 理想としては導入すべき。
      • だが、場合によってはかけたコストを回収できない可能性も。
      • 3ヶ月以上、開発者?人位の中規模程のプロジェクトなら十分回収できるので試すと良い。
  • 発展課題(詳細は資料をご参照ください。)
    • Jenkins(CI)のTips
    • おススメのJenkinsプラグイン
      • Jenkinsの作業ディレクトリ
      • クリーンビルド
      • ビルドとデプロイの分離
      • ビルドと時間のかかるジョブの分離
    • 継続的デリバリー

この辺りの環境を導入し、広めて行くのって割と長い道のりであり、手順として表に多く出てきているものでもないと思うので、順を追って流れを追えるというのはとても助かりますね。大いに参考にさせて頂こうと思います。

座談会

今回の読書対象範囲は第15章。Takeshi KOMIYA(TwitterID:@tk0miya)さんによるファシリテートの元、ディスカッションが進められて行きました。

第15章 継続的インテグレーション：リリースに備える
    15.1 ショータイム
    15.2 リリースに備える文化
    15.3 継続的インテグレーションとは
    15.4 どうすればうまくいくのか？
    15.5 チェックイン手順を習慣づける
    15.6 ビルドを自動化する
    15.7 作業単位を小さくする
    15.8 この先どこへ向かえばいいのか？
  • 15-1.デモの準備を済ませなければならん
    • バージョン管理してれば一大事シナリオは無いはず…
    • 入れるものを制御出来ないとしっちゃかめっちゃかになる
    • 不安なコードの塊の場合、どうする？
    • 不安なコードが入らなくなるというタイミングがあると気分が違う
    • 勝手に導入できない…交渉の必要がある。
      • この状況は悲鳴的、致命的。
    • ショートのスパンでデモする際に、準備出来る状況にあるのか？
    • いつでも価値を提供する、という視点から見れば大混乱している状況。

    • 日常茶飯事シナリオ
      • 5分に渡る格闘の末…テストは手動(悲劇的シナリオ)
      • チェックイン5分…こちらは自動。
        • アメリカンドリームなシナリオ?
    • 理想論と現実論(オンザフライで修正したい)
      • 本番サーバのファイルを直に修正をやりたいから自動化をやりたくないんだ...という声もある。
      • 作業的に間に合っちゃうよね、という話
        • 『色々合ったけど上手く行ってよかったね〜』という点に着地してしまう人も居る。
        • トラブルが起きた時にサーバ上のものをアドホックで直すのはあり。だがそれをバージョン管理してないのはNG。(※クビか減給モノだろ！)
        • 例外ケースも有ると思うが、普段の作業は安全側に倒さないと行けない。
        • 組織やチームではなく個人の判断でその辺りの作業判断を決められてしまう？
        • 変更したものをバージョン管理してないのなら、バージョン管理使わないほうがいいんじゃない？
        • バージョン管理しない、避けるような人はチケット管理等も避ける傾向がある。(そういう人たちの考えって)治るのか？
  • 15.2 リリースに備える文化
    • リリースの習慣を身につけるのは簡単なことでは無い。
  • 15.4 どうすればうまくいくのか？
    • どこでコードレビューを入れる？
    • Svnならチェックイン前に。
      • →レビューの時間がCIを阻害する要因にならないか？
        • レビュー者の数の問題、体制の問題では。
      • (対応方法として)レビュー内容についても、そこまで深く追わない。それで大きなミスは防げるだろう。
        • 実際後半バグが出る率が減った。
    • ペアプロの項もあるので、この書籍ではその辺(レビューに)触れていないのか？
    • コンテキストにもよる部分もあるので、一概にこうとは言えない。
    • 中央集権的、svn等だとコミットも大きくなってしまう。
    • コミット頻度・粒度に関する議論
    • コミット前・後何時にレビューをするかの議論
    • ブランチを切ってレビューをすれば？
      • ブランチの話はもう辞めてくれ…(心の叫び)
    • svnのまま頑張るなら、hg-subversion等のツールを使って頑張った方がいいのでは？
  • 15.5 チェックイン手順を習慣づける
    • 習慣づけましょう！
    • ビルドを大事に…壊す人についての議論
    • テストファーストとTDDの話
      • テスト結果を二分探索
      • JapaneseBisectExtension - Mercurial
        • 二分探索(O(log(n)))を用いてバグ探しの手間を軽減。
      • Red-green-refactaringの流れの中で、どこでプッシュすべきか？
        • ビルドが壊れないようなプッシュ方法をおすすめします。
        • コミット溜めてしまえる、長時間掛かるようなものでなくても想定する状況は発生する。
        • テストコードを書いてないとbisectは常に成功してしまう。
        • 失敗したものを見つけていくものなので
  • 15.7 作業単位を小さくする
    • 『一般的なプラクティスだ』…一般的...なの？
    • 作業単位を小さくする…機能リリースとの兼ね合い
      • ブランチ戦略によって対応？

スイーツタイム

会の中盤には豪華スイーツタイムも。参加者の皆さんが様々なものを持ち寄っておられ、非常に豪華なひとときとなっておりました。皆様ありがとうございました！美味しゅう頂きました♪

LT

ここからはLT祭り。計3名の方によるLTセッションが行われました。LTという割には結構皆さんボリュームがあったような気も。:-)

LT:継続的インテグレーション3分クッキング


『JenkinsとMercurialを使って、ビルドやテストが通ったものだけを中央リポジトリにpushする』環境について、諸々の解説を交えながらハンズオン形式で進めて行く、というもの。環境的には以下のような構成でした。(詳細は既にスライド資料が上がっているため割愛)

LT:History of Waterfall(増補改訂版)

以前、『アジャイルサムライ読書会 横浜道場』某回の懇親会にて、闇LT的に発表されたものが元。発表後の反響が大きく、このタイミングでボリューム増＆再演となりました。初出典版はこちら。

こちらのメモについても、前回の資料もあったりスライド資料が既にUPされているのもあるので割愛します。

LT:継続的デリバリー単報(環境編)


継続的デリバリーの内容に感銘を受け、実際に環境構築を行った内容についての調査結果・まとめ的なLT。こちらも非常にてんこもり、充実の内容で、LT時間枠では収まらず懇親会でも続きを行うほどでした。

内容については未完・調査中の部分もあるため、資料公開については後日まとまった時点で、という事です。Chef等を使った自動化の部分も多々あるため、内容の公開が非常に待ち遠しいLTでした。以下ざっくりメモ。

  • 自己紹介
    • Block-diagの中の人
    • Sphinx-users.jpのエライ人
    • 新宿道場　道場主補佐（通称：ヒラ）
    • お知らせ：
  • 問題
    • 開発環境が壊れた。再構築が面倒
    • 歴史的経緯であの環境だけXX
    • 環境つくり用の手順が複雑
    • 新入りさん、初日は環境構築ね！
  • 余計なコストを減らそう！
    • 目標
      • 環境をバージョン管理せよ
      • 開発/本番環境構築の自動化
      • 楽したい
      • 継続的デリバリーに感化されまくり
  • 利用するソフトウェア
    • chef(chef-solo)
      • 環境構築ソフトウェア
      • パッケージ、設定を自動的に最新に保つ
      • 今回はchef-soloのみ、serverは使わない
    • vagrant
      • virtual boxの管理ソフトウェア
  • Chef+Vagrantによる環境構築
    • 開発環境
      • vagrant で開発用VMを作る
      • Chefで環境構築
    • 本番環境
      • Chefで環境構築
      • アプリのデプロイは別途capistranoで！
  • vagrant
    • インストール方法
  • vmイメージの作り方（基本）
  • 設定ファイルの書き方
  • VMイメージの動かし方
    • 起動
    • 管理ログイン
    • 終了
    • 破棄
  • VMイメージのテンプレートどうする？
  • VeeWee

LT枠時間の最後には、OSインストール等の自動化作業を実演。

懇親会

本編終了後、そのまま同じ場所で懇親会へ。会の途中では小宮さんのLT後半戦であったり、各自KPTの内容を元にふりかえりを実施(当エントリTOP画像もその時のもの)したりとこちらも内容盛り沢山、和気あいあいとした雰囲気で過ごすことが出来ました。

14時から始まり懇親会が終わったのが21時。計7時間(本編4時間、懇親会3時間)の超長丁場！ 内容も濃かったので、終わったころにはだいぶぐったりしていました...(^_^;)(笑) 新宿道場の皆さん、毎回この規模で道場参加をされてきたのはスゴイの一言ですね。

これまで参加してきた(道場の)中では、技術的な側面の話が多かったのも印象的でした。Jenkins周りについては職場や個人的なプロジェクトで利用し、使いこなしたい部分でもありますし、Chef等のサーバ作業自動化についても、先日自宅鯖を移行すべくさくらVPSを契約したのもあり、サーバ構築自動化作業に関してもこの辺の技術を使って実現・効率化出来ればなぁ〜と淡く思ってたりします。(まぁ淡くなので自動化自体は何時になるか分かりませんがw)

当初次回(最終回)開催は9/1(土)と言う予定のようでしたが、懇親会での流れで行くとどうやら8月にも第9回が開催される雰囲気。(9/1開催が第10回:最終回？) 新宿道場も残りあとわずかですが、興味のある方は是非参加してみてはいかがでしょうか。


その他関連：