読者です 読者をやめる 読者になる 読者になる

デブサミ2012 2日目 (2012/02/17)のまとめ その1 #devsumi

参加セッション

  • 【17-A-1】Jenkins 川口 耕介 氏
  • 【17-C-2】仕事のバトン、渡っていますか? - プロジェクト管理におけるコミュニケーション基盤作り
  • 【17-B-3】言語の世界 まつもと ゆきひろ 氏
  • 【17-A-4】Scrumで変わる組織貝瀬 岳志 氏
  • 【17-B-5】アジャイルマニフェスト ディケイド 角谷 信太郎 氏-【17-C-6】ライターズ・フィロソフィー―IT業界で書いて食っていくひとたちの哲学をきこう 西村 賢 氏 / 毛利 勝久 氏 / 五味 明子 氏 / 小泉 真由子 氏
  • 【17-E-7】君の4tate(立てた帆)に、風を感じているか? 〜4tateで日本を変えるプロジェクト〜 野村 恭彦 氏 / 市谷 聡啓 氏

まずは2セッション分

【17-A-1】Continuous DeliveryとJenkinsアブストラクト川口 耕介 氏


Jenkins

プロジェクトリーダー
CIサーバ
流行っている理由
使うのが簡単
プラグインでさまざまな環境に適応
450+

風呂敷を広げて
CIサーバがどうして必要か

ムーアの法則
シングルスレッドの性能は頭打ち
IntelSparcでも同じ

メインは、スレッドの数
大きなパラダイムシフト

性能あたりの値段も下がっている

計算能力の向上

どんどん増えてる
どんどん安くなる

人間の性能は向上していない
もしかすると下がっている

ますます計算機をうまくつかっていくことが必要

頭数をそろえて人海戦術
→計算機を集めて
→計算機の力をかりて
クラウド

  • 物理的な数も増えてる
  • 見かけのマシン数も増えてる
  • 数が増える
    • が人間が面倒できるマシンが少ない
  • イメージ羊飼い
    • 羊のような膨大なマシンを率いていく
  • VMは計算機をスライスするだけではない
  • 時間的にテンポラリに割り当てることができる
  • デプロイへの影響
    • 2台のサーバを使って、新しいバージョンに問題があったら古いバージョンに戻す
  • 時間と台数の交換が可能
    • 以前は長い時間がコストを回収
      • 1ヶ月から1時間へ
    • 小さなスケールで並列化
      • 横に並べればいい
        • テストの効率化などしなくてもよこに並べればいい
  • あらゆる階層でのテストの並列実行
    • 複数スレッドで
    • 複数のプロセス
    • 複数プロセスセスで
  • クラウド、仮想計算機
  • 自動化への拍車
    • Chef、Puppet
    • 他の巨人が築いてくれたツールを使うことで自分も恩恵も受け入られる
開発ツールの自動化の進展
  • VS→MSBuild
  • 実行結果を機会可読にする
  • 対話Onlyはありえない
開発ツール自動化の天王山
SaaSの台頭
  • サービスとしてテストツールを使用する
  • Seleniumをサービス
  • モバイル端末を時間貸し
  • Jenkins のサービス
  • プロビジョニングも急速・簡単・自動
  • 交換可能な時間の単位1分
  • 1分単位で並列化してもコストがかからない
  • 並列化するメリットが大きい
  • 並列化を避けてとおれない
  • いろいろなレイアーで自動化をすることが簡単になってきた
    • 計算機、OS、ミドル、ツール
  • コーディネートを人間がやっていては間に合わない
  • それをする執事のようなソフトウェアが必要
Jnekins

分散ビルドに対応して5年
100以上のノードをつなげているものはごろごろある
プラットフォームとしてとらえて欲しい

コミットの検証済みマージ
  • CIのジレンマ
    • ローカルの仕事をサーバ側に移った?
    • サーバにしてもらうにはコミットが必要
    • コミット、他のチームのメンバにリリースするという意味
    • コミットが壊れていたら他に迷惑がかかる
    • ビルドを壊さないために、ローカルでテストする
  • 大規模プロジェクトのジレンマ
    • ある一定の程度で問題が生じる確率が増える
    • 人が増えると、100%に近づく
    • レガシーなコードでモジュール化がうまくいかない
  • 検証済みマージ
    • 開発者はブランチにコミットする
    • Jenkinsがブランチをテストする
    • OKならbJenkinsがトランクにマージする
    • 問題のあるコードはTrunkにはいらないので、Trunkが安定
    • rebaseを使えば、trurnkからあまり外れない
  • 利点
    • 間違いをしても他人に影響しない
      • 気軽にコミット
    • テストはサーバできる
      • 大規模なテスト、
      • フルセットのテストを流せることができる
      • 環境依存のテストも
      • メンテナスになると特に有効
    • テストは非同期に走る
      • 満足したら変更したら、すぐに次の作業に
      • テスト待ちをなくすことで生産性向上
                 Master repo
          /                   \
    team repo     team repo     team repo
    /    \      /   \        /     \
  開発者 開発者  開発者 開発者  開発者  開発者

WEB+DB PRESS Vol.67 でも






川口 耕介、山本 和彦、大和田 純、白土 慧、太田 昌吾、個々一番、Shawn M Moore、清水 亮、じゅんいち☆かとう、小野 修司、おにたま、神林 飛志、杵渕 朋彦、中島 聡、齋藤 正浩、高橋 征義、ミック、みやけん、WEB+DB PRESS編集部
価格: ¥ 1,554


価格は記載時点のものです。購入前にAmazonでご確認ください。






デプロイメントの自動化
  • ビルドができたらどこかで動かそう
    • ユーザー、QAへの効果へ

デプロイされる前に検証

  • できたビルドを検証する
  • コンパイルが遠た≠デプロしても良い
  • ビルドパイプライン
    • 徐々におおgかかりなテストを実行
    • 失敗したらそこでストップ
    • ふるいにかける
  • パイプライン:その1
    ビルド
        統合テスト
            品質検査
                デプロイ
    • 上流、下流プロジェクトを繋ぐ
         ビルド ビルド ビルド
            ↓               ↓
      結合テスト         結合テスト
             ↓
            デプロイ
  • 選ばれたエリートだけがデプロイされる
  • ビルドパイプライン・プラグイン
  • Promoted Buildプラグイン
  • プロセスフローではなくて、状態遷移を考える
    • イメージとしてはSNSのバッチ
    • 特定条件を満たした場合に得られる称号
  • 「状態」だとおもしろい
    • 人間がOK
    • 時間
  • 昇進モデルの利点
    • 非同期
    • コードに問題がある場合、テスト環境に問題がある場合
      • パイプラインの途中からやり直せられる必要がる
    • チームからチームへの引継ぎは「状態」の方がいい
      • 「締め切り間際で、まだカバレッジがとれてない、俺が責任がとるからいいからデプロイして」がなくなる
      • 安定的
    • チームとチームを横断した自動化が自由
      • その上でチームに裁量権を与える
    • トリガの呪縛から解放
トレサビリティが大事
  • 追跡の重要性
  • ユッケ食べられなくて残念
    • どの流通されたかを調べる必要がある
  • 機械による追跡可能性
    • Dev:コミットID
    • QA:バグID
    • QA:テストの実行記録
    • Op:デプロイの記録、現在実行中のバージョン
      • 俺の頭の中の場合も
CIサーバは3界の架け橋
追跡可能性とパイプライン
  • WF型パイプライン
    • チェックサムが重要
    • プロセスの自由度を上げながら追跡可能性をあげる
  • プロジェクトの相関関係
  • 上流プロジェクトと下流プロジェクト
  • フィンガープリント
    • 職域をまたがって、それぞれの人がやっていることを、全体を見ることができる
バイナリインテグレーションのススメ
    • バイナリをリビルドしない
    • 時間の制約
    • 追跡性の向上
    • 環境による差異
分散バイナリリポジトリ
  • コミットと共有の分離
    • ソースコードの集合に識別をつける
      • レビュー済み
    • CIサーバに送りたいのか
    • 開発者と共有したいのか
    • 永続的に残したいのか
  • 同じことがバイナリについても言える
自動化による相乗効果
  • Dev、Op,QAのあらゆる局面で自動化が進んでいる
    • 隣接する人たちの自動化を連携する必要がでてきた
  • 自動化の島がつながる
3種の神器 から新・3種の神器へ
  • デプロイスクリプト
    • デプロイメントまで
    • 人がいなくても
  • XaaS
    • 時間とコストを短く変換する
  • クラウド
    • より大きな相乗効果


計算機は湯水につかえるようになる、今からその計算能力を
活用することを考えていないと困ることになる


Jenkinsはこういうニーズを吸収していく

使っていない人は使い始めて欲しい
使っている人は次のステップへ進んで欲しい

【17-C-2】仕事のバトン、渡っていますか? - プロジェクト管理におけるコミュニケーション基盤作り

今日はノウハウの話

グロースエクスパートナーズ SIer

  • 課題管理ツール使っている人?→ 6割
  • もっとうまい使い方があるんじゃないかという人? →3割
  • Excelを使っている人? →1割ぐらい

PJでおきてること

  • 明確なことと曖昧なことが混ざり合う
  • 仕様
  • 参画するメンバー
  • 開発方法論は関係ない
    • 明確なことが多いことが場合はWF
      • パケージの適用はWFが向いている
    • 曖昧なことが多い場合はアジャイル
      • リスクを取る
  • 曖昧なことを明確にする
  • 明確になっったら計画をたてていく
  • どんなに明確でも不確定(リスク)なことが残る
    • 新しく発見したナニカ
      • バグ
      • 問い合わせ
      • 課題
      • リスク
      • 新しい仕様
  • 不確定なものにどう立ち向かっていくか
  • 不確定さを予測する
    • このぐらいのバグ
      • ソースコードの全体量
      • 機能数、ファンクションポイント
      • バグ密度
    • これぐらいの仕様変更
    • 時間枠の中で、その不確定さの幅にい収まっているか判断する
      • タイムボックス型
        • アジャイルは、先に箱を決める
        • あふれていないかを計測していく
        • 不確定要素がすくないのも問題
そこで「課題管理」が重要
  • 課題管理
    • 内容
    • 発生日
    • 重要度・影響度
    • 担当者
    • 期限
    • 状態
  • どう管理するのがよいか?
  • Excel最強
    • 自由にカスタマイズできる
      • 項目を足したり引いたり
      • マクロ
    • 分析
      • ピボットテーブル、ピボットグラフ
    • 多くのPCに入っている
      • Excelが入っていないと言われることはない
    • 印刷可能

仕事のバトン

  • 仕事は一人じゃ完結しない
    • 構成要素が複雑
    • スキルが広範囲
  • 成果物
    • タスク
  • プロストして並べていく
  • スケジュールに落としていく
  • テスト工程
    • バグを発見→修正→デプロイ→確認する
    • 規模が大きくなると役割ができてくる
  • アクター
    • テスター→エンジニア→デプロイヤ→テスタ
    • ありがちな問題
    • エンジニア
      • もう直ってるよ
      • ていうか俺の担当じゃない
    • テスター
      • いつ直ったの?
      • 誰が直したんだよ?
    • デプロイヤ
      • どれをリリースすればいいんだ?
将来渡される人
  • バトンが渡される人はいつぐらいに渡されるか知りたい
  • 俯瞰して全体的に状態を見てる人は、問題を解決していく必要がある
  • 「仕事のバトン」がどこにあるのか
  • あるときは同期、ある時には非同期にするイベントがある
  • Excelでは足りない
    • できないではない
    • ファイルを配ってしまうのでマージが大変になる
  • 個人、自己管理であれば、Excelで十分

課題管理ツール

JIRA
  • JIRAの固有の話ではなく、課題管理ツール一般的な話
  • オーナー、除隊
  • 横断的にくくるフラグを制御
  • 適用箇所
    • まずはテスト工程
  • JIRAだとバージョンという概念が最初から入っている
  • 1枚のチケットを渡していく
  • 状態の意味づけにルールを当てる
  • バージョンをつけると、どのリリースに含まれるかがわかりやすい
  • テスト以外の適用箇所
    • 顧客とのQ&A管理
    • オフショア先やチーム間
    • この場合はあまりバージョン機能は大事ではない
  • 実装管理用、Q&A用の管理が独立している
  • 分けている理由
    • SIerには秘密がある
      • 今日言うとややこしいから、明日に言おうといった事情がある
    • 全公開でやるなら1つでいいが、多くのSIerは分けた方が幸せになるのではないか?
    • JIRAだと双方向リンクがあるので、問題ない
  • SCM、お客さんとのコミュニケーションを俯瞰してみるといい
管理するコツ
  • 起票のルール
    • 気遣い重要
      • 言葉遣いは丁寧に
      • →くだらないコメントの応酬は効率が悪くなる
      • →できない人間は厳しく叱る
    • コミュニケーションツールとして認識してもらうため
    • 事実を書く
      • これはどっかで探してください
  • プロセスを決める
    • 完了責任を負う、クローズを誰がするかをきめる
    • 教育
    • 抱えがちには棚卸を定期的に促す
      • Weekly
      • Daily
      • チームごとのリズムで
    • チケットを発行しがち
    • 細かくなりがち
  • リーダーに使ってもらう
    • 溜めがちな人が誰だか分かる
    • PMのツールとして使ってもらう
  • JIRAの強み
    • 複数のプロジェクトで使うことができる
    • セキュリティ
      • 中央に事務局があったほうがうまくいく
      • 誰にどのような権限があるのか
    • マルチプロジェクト
  • 応用編
    • 品質管理
      • バーンダウンチャート
      • 独自のフィールド
        • バグの原因
  • チケット駆動開発
    • レベルが高い
      • 相当難しい
    • チケットいつ発生するかわからない
    • いつ何をつくるかは決まっている場合は、いちいちチケットを発行する必要がない
    • 時間軸のバランス感覚が分からなくなる
    • 日付の前後が分かりにくい
      • 不確定要素
      • バグ
      • 問い合わせ
    • プロセスやアーキテクチャが安定している必要
    • チケット駆動にしたからといってプロセスが安定しているわけではない
    • 運用、改善フェーズはよい
    • ある程度溜まったらリリースしよう
    • アンチパターン
    • 計画的なものに使おうとする
      • 計画的なものExcel、MS-Projectの方が便利
      • ワークフローやフィールドを設定しすぎる
      • デフォルトの設定で困ることはあまりない
      • →運用でカバーできる
    • タスクを階層化しすぎる
      • 子供タスクは使いすぎない
      • 個人的には使う必要がない
      • 子供1、2、3が終わったら親がクローズ
      • その粒度で本当に管理していく
  • 複数のコミュニケーションツール(課題管理ツールとメールでの依頼)を併用するのはダメ
    • メールや電話での内容を登録する
    • 啓蒙する必要がある
    • 必ず記載してもらう
    • 併用するなと、メールや電話をするなということは別
    • JIRAで喧嘩
    • 時間管が重要
  • タイムボックスで区切りを管理
    • 課題管理ツールが先にある場合
      • アジャイルやチケット駆動は時間間隔が決まっている場合なら
    • WBSなき課題管理ツールは失敗する
      • →時間枠の中で不確定なことを管理する
      • 計画して確定しているつもりでいれたタスクをチケットにするとうまくいかない
    • 他人へのお願いもうまくいかないことが多い。
      • コミュニケーションツールということを
  • 使ってみるならバグとQ&Aから
  • 運用フェーズもおすすめ
  • 管理は少しずつ複雑に
  • 仕事のバトンを渡していく工夫
    • 課題番号
      • 1回発生したIssueを長く使っていく
広告を非表示にする