アジャイルサムライ読書会で @troter 先生の話を聞いてきた

イベントページ

http://connpass.com/event/652/


もうだいぶ前なんですけど下書きしたまま清書するの忘れてたとか何とか言う…的なアレで、今更ですがエントリ化しておきます。
感想としては、やはり導入に際して先導者にはそれなりの覚悟とかリソースとか知識が求められるなー、と言う感じ。
とは言えCIというインフラ、自動化のための仕組みは未来の自分やプロジェクトを救うので、挑戦したり修得する価値は十二分以上にある、と言うかもう出来ないじゃ済まされないんだろうなぁ。

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

資料
https://docs.google.com/presentation/d/1pfmrMYNS9t6f15TM8HKjGnRxECIaw1YxUNaW-KB_gjU/edit

  • 継続的インテグレーションとは
    • ツールではなくプラクティスの事
    • コミットするたびに結合
    • コミットする度に以下を実行
      1. コミット
      2. チェックアウト/クローン
      3. ビルド
      4. テスト
      5. インスペクション(カバレッジとか静的コード解析とか)
    • 色んなツールがある。何を使ってもいい
    1. まずは説得
      • 何をするにも味方の存在が重要
      • 見込みのある同僚を確保し、次の本を与えます
      • 出来れば上司に掛け合う
    2. CI用マシンの確保
      • 型落ちのPCやVMでOK
      • あるいはEC2とか
        • CPUはその時で一般的なもの
        • メモリ1.5GBぐらい
        • ディスク30GBぐらい
      • CI用マシンにはビルドとテストの実行に必要なソフトウェアをすべてインスコする必要がある
        • ライセンスの確保とかが必要な場合は頑張ってください
      • CI用マシンはテストを実行する都合上、デプロイ環境と同じ構成にするのが好ましい
        • OS、インストールするソフトウェアなど
    3. CIサーバ構築のための時間の確保
      • 0から構築する場合ビルドツールの調査を含めだいたい2週間ほどの作業が必要
        • 片手間の場合。専念してもいいならもう少し早いかも
    4. CIサーバ構築のための準備
      • VCSの用意
      • ビルドの自動化
        • JavaならMaven、Gradle
        • PHPならPhingとか
        • ビルドツールから.project等のIDEの設定ファイルを生成してしまうのがおすすめ
          • 開発環境や設定も統一できる
          • ただし結構面倒くさい
          • IDEのバージョンアップで設定ファイルの記述が変わる場合もあるので追跡しておかないといけない
        • IDEとの関係(.NET)
          • ソリューションファイルをコミットする
          • ファイルを追加するたびにソリューションファイルをコミットする事になるけど頑張る
      • ユニットテストの自動化
        • ビルド自動化で使ったビルドツールやユニットテストツール付属のテストランナーで自動化する
          • ビルドの自動化が出来てればテストの自動化自体は楽
          • テストが通るかどうかとは別問題!!1
    5. CIサーバ構築
      • Jenkinsが一番楽
        • OS毎にパッケージがあるのでそれを使うのおすすめ
      1. 開発ツールのインストール
        • CIサーバに開発ツールやテストに必要なツールをインストールする(DBサーバも含む)
      2. Jenkinkプラグイン
        • Jenkinsをインスコ後ジョブを作成する前にプラグインをインストールする
          • VCS
          • ビルドツール系
          • 超いっぱいあるので欲しい物をインストール
      3. ジョブの作成
    6. メンバーの教育
      1. VCSの使い方講座
        • VCSを変更する場合は説明会を開催する
        • scmbcの資料おすすめ
        • ハンズオンの開催も効果的
        • みんなで覚えようとするのが大事
      2. VCSの効果的な使い方講座
        • 使い方に慣れたらより効果的な使い方を覚えよう
          1. 一度に一つの変更を行う
          2. コミット前、プッシュ前にテストを動かす
        • ソースツリーを壊さない、迷惑をかけない
      3. DVCSの場合は履歴改変方法を覚える
        • 変更点をより論理単位に出来る
      4. テストの書き方
        • CIサーバの構築後にテストの書き方を共有する
        • いきなり完璧を目指すと挫折する
          • スモークテストでいい
          • テストを書くことを目的にする
          • テストがあればCIサーバが勝手に動かす
          • 以下のステップがおすすめ
            1. 正常系スモークテスト
            2. モデル、コントローラの単体テスト
            3. モデル、コントローラの結合テスト
    7. 全部終わったら?
  • よくある質問
    1. CIサーバの構築はいつやるの?
      • イテレーションゼロで完了させるべき
      • スケジュールに構築作業を組み込みたい
      • スケジュールに組み込めない場合は業務時間外にやるしかない
    2. 途中から導入したい時は?
      • 説得してスケジュールを確保する
    3. CIサーバ構築初めてです不安です時間がかかります
      • 練習するしか無い
      • Jenkinsならダウンロード含めて1時間ぐらいで立つ
    4. 対象言語のビルドツールに習熟してない
      • 頑張れ
      • CIはビルドツール、CIサーバ、shell、batの知識がないと何も出来ない
    5. どんなプロジェクトでも導入すべき?
      • 理想としては導入すべき
      • 導入に慣れてない、短期間プロジェクトなどの場合はかけたコストを回収できない可能性も
      • 3ヶ月以上、開発者5人くらいの中規模プロジェクトなら十分回収できるので試してみればいい
  • 発展課題
    • Jenkinsの作業ディレクト
    • ビルド前にかならずワークスペースをクリアする
      • 以前のビルドの影響をなくすため
      • 設定ファイルの混在など
      • 実現方法
        • ビルドツールのクリーンタスクを実行
        • もしくはジョブの設定でクリーンビルドを実行
        • mavenの場合は専用のmavenリポジトリを利用するをチェック
    • 時間の掛かるジョブの分離
      • インスペクションは時間がかかるので通常のビルド、テストのジョブとは分離する
      • 実現方法
        • 深夜に1回実行とか
    • ビルドとデプロイの分離
      • 変なものをデプロイしないようにするため
      • デプロイするたびにビルドするのは時間かかりすぎる
      • 実現方法
        • ビルドの後続ジョブとしてデプロイを指定
        • 成果物の受け渡しにはcopy artifact pluginを使う
    • 継続的デリバリー
      • CIの資産を活かせる
  • まとめ
    • 一歩一歩やればCIは必ず導入できる
      • ただし自己犠牲が必要なことも
    • 導入すると道がひらける
      • CIサーバを中心に様々なものが自動化出来る

@shin_semiya History_of_waterfall

資料
http://slidesha.re/Nys59O

ウォーターフォールの歴史について。
ウォーターフォールというプロセスが輸入された後、輸入元の方では種々の問題(プロジェクト炎上)により、とっととイテレーティブなプロセスに移行してた。
必死にこいてRun Onceなウォーターフォールモデルを堅守してるのは日本だけだったと言う話が面白かった。