デブサミ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サーバがどうして必要か
ムーアの法則
シングルスレッドの性能は頭打ち
Intel、Sparcでも同じ
メインは、スレッドの数
大きなパラダイムシフト
性能あたりの値段も下がっている
計算能力の向上
どんどん増えてる
どんどん安くなる
人間の性能は向上していない
もしかすると下がっている
ますます計算機をうまくつかっていくことが必要
頭数をそろえて人海戦術
→計算機を集めて
→計算機の力をかりて
クラウド
- 物理的な数も増えてる
- 見かけのマシン数も増えてる
- 数が増える
- が人間が面倒できるマシンが少ない
- 聖徳太子も7台まで
- が人間が面倒できるマシンが少ない
- イメージ羊飼い
- 羊のような膨大なマシンを率いていく
- VMは計算機をスライスするだけではない
- 時間的にテンポラリに割り当てることができる
- デプロイへの影響
- 2台のサーバを使って、新しいバージョンに問題があったら古いバージョンに戻す
- 時間と台数の交換が可能
- 以前は長い時間がコストを回収
- 1ヶ月から1時間へ
- 小さなスケールで並列化
- 横に並べればいい
- テストの効率化などしなくてもよこに並べればいい
- 横に並べればいい
- 以前は長い時間がコストを回収
- あらゆる階層でのテストの並列実行
- クラウド、仮想計算機
- 自動化への拍車
- Chef、Puppet
- 他の巨人が築いてくれたツールを使うことで自分も恩恵も受け入られる
SaaSの台頭
- プロビジョニングも急速・簡単・自動
- 交換可能な時間の単位1分
- 1分単位で並列化してもコストがかからない
- 並列化するメリットが大きい
- 並列化を避けてとおれない
- いろいろなレイアーで自動化をすることが簡単になってきた
- 計算機、OS、ミドル、ツール
- コーディネートを人間がやっていては間に合わない
- それをする執事のようなソフトウェアが必要
Jnekins
分散ビルドに対応して5年
100以上のノードをつなげているものはごろごろある
プラットフォームとしてとらえて欲しい
コミットの検証済みマージ
- CIのジレンマ
- ローカルの仕事をサーバ側に移った？
- サーバにしてもらうにはコミットが必要
- コミット、他のチームのメンバにリリースするという意味
- コミットが壊れていたら他に迷惑がかかる
- ビルドを壊さないために、ローカルでテストする
- 大規模プロジェクトのジレンマ
- ある一定の程度で問題が生じる確率が増える
- 人が増えると、100%に近づく
- レガシーなコードでモジュール化がうまくいかない
- 検証済みマージ
- 開発者はブランチにコミットする
- Jenkinsがブランチをテストする
- OKならｂJenkinsがトランクにマージする
- 問題のあるコードは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
ビルド
統合テスト
品質検査
デプロイ
-
- 上流、下流プロジェクトを繋ぐ
ビルド ビルド ビルド
↓ ↓
結合テスト 結合テスト
↓
デプロイ
- 選ばれたエリートだけがデプロイされる
- ビルドパイプライン・プラグイン
- 「状態」だとおもしろい
- 人間がOK
- 時間
トレサビリティが大事
- 追跡の重要性
- ユッケ食べられなくて残念
- どの流通されたかを調べる必要がある
- 機械による追跡可能性
- Dev：コミットID
- QA：バグID
- QA：テストの実行記録
- Op：デプロイの記録、現在実行中のバージョン
- 俺の頭の中の場合も
追跡可能性とパイプライン
バイナリインテグレーションのススメ
-
- バイナリをリビルドしない
- 時間の制約
- 追跡性の向上
- 環境による差異
分散バイナリリポジトリ
- コミットと共有の分離
- ソースコードの集合に識別をつける
- レビュー済み
- CIサーバに送りたいのか
- 開発者と共有したいのか
- 永続的に残したいのか
- ソースコードの集合に識別をつける
- 同じことがバイナリについても言える
自動化による相乗効果
- Dev、Op,QAのあらゆる局面で自動化が進んでいる
- 隣接する人たちの自動化を連携する必要がでてきた
- 自動化の島がつながる
3種の神器 から新・3種の神器へ
計算機は湯水につかえるようになる、今からその計算能力を
活用することを考えていないと困ることになる
Jenkinsはこういうニーズを吸収していく
使っていない人は使い始めて欲しい
使っている人は次のステップへ進んで欲しい
【17-C-2】仕事のバトン、渡っていますか？ - プロジェクト管理におけるコミュニケーション基盤作り
デブサミ2012「仕事のバトン、渡っていますか？」
View more presentations from yusuke suzuki
今日はノウハウの話
グロースエクスパートナーズ SIer
- 課題管理ツール使っている人？→ 6割
- もっとうまい使い方があるんじゃないかという人？ →3割
- Excelを使っている人？ →1割ぐらい
PJでおきてること
仕事のバトン
- 仕事は一人じゃ完結しない
- 構成要素が複雑
- スキルが広範囲
- 成果物
- タスク
- プロストして並べていく
- スケジュールに落としていく
- テスト工程
- バグを発見→修正→デプロイ→確認する
- 規模が大きくなると役割ができてくる
- アクター
- テスター→エンジニア→デプロイヤ→テスタ
- ありがちな問題
- エンジニア
- もう直ってるよ
- ていうか俺の担当じゃない
- テスター
- いつ直ったの？
- 誰が直したんだよ？
- デプロイヤ
- どれをリリースすればいいんだ？
課題管理ツール
JIRA
- JIRAの固有の話ではなく、課題管理ツール一般的な話
- オーナー、除隊
- 横断的にくくるフラグを制御
- 適用箇所
- まずはテスト工程
- JIRAだとバージョンという概念が最初から入っている
- 1枚のチケットを渡していく
- 状態の意味づけにルールを当てる
- バージョンをつけると、どのリリースに含まれるかがわかりやすい
- テスト以外の適用箇所
- 顧客とのQ&A管理
- オフショア先やチーム間
- この場合はあまりバージョン機能は大事ではない
- 実装管理用、Q&A用の管理が独立している
- 分けている理由
- SCM、お客さんとのコミュニケーションを俯瞰してみるといい
管理するコツ
- 起票のルール
- 気遣い重要
- 言葉遣いは丁寧に
- →くだらないコメントの応酬は効率が悪くなる
- →できない人間は厳しく叱る
- コミュニケーションツールとして認識してもらうため
- 事実を書く
- これはどっかで探してください
- 気遣い重要
- プロセスを決める
- 完了責任を負う、クローズを誰がするかをきめる
- 教育
- 抱えがちには棚卸を定期的に促す
- Weekly
- Daily
- チームごとのリズムで
- チケットを発行しがち
- 細かくなりがち
- リーダーに使ってもらう
- 溜めがちな人が誰だか分かる
- PMのツールとして使ってもらう
- JIRAの強み
- 複数のプロジェクトで使うことができる
- セキュリティ
- 中央に事務局があったほうがうまくいく
- 誰にどのような権限があるのか
- マルチプロジェクト
- 応用編
- 品質管理
- バーンダウンチャート
- 独自のフィールド
- バグの原因
- 品質管理
- チケット駆動開発
- レベルが高い
- 相当難しい
- チケットいつ発生するかわからない
- いつ何をつくるかは決まっている場合は、いちいちチケットを発行する必要がない
- 時間軸のバランス感覚が分からなくなる
- 日付の前後が分かりにくい
- 不確定要素
- バグ
- 問い合わせ
- プロセスやアーキテクチャが安定している必要
- チケット駆動にしたからといってプロセスが安定しているわけではない
- 運用、改善フェーズはよい
- ある程度溜まったらリリースしよう
- アンチパターン
- 計画的なものに使おうとする
- 計画的なものExcel、MS-Projectの方が便利
- ワークフローやフィールドを設定しすぎる
- デフォルトの設定で困ることはあまりない
- →運用でカバーできる
- タスクを階層化しすぎる
- 子供タスクは使いすぎない
- 個人的には使う必要がない
- 子供1、2、3が終わったら親がクローズ
- その粒度で本当に管理していく
- レベルが高い
- 複数のコミュニケーションツール(課題管理ツールとメールでの依頼)を併用するのはダメ
- メールや電話での内容を登録する
- 啓蒙する必要がある
- 必ず記載してもらう
- 併用するなと、メールや電話をするなということは別
- JIRAで喧嘩
- 時間管が重要
- タイムボックスで区切りを管理
- 使ってみるならバグとQ&Aから
- 運用フェーズもおすすめ
- 管理は少しずつ複雑に
- 仕事のバトンを渡していく工夫
- 課題番号
- 1回発生したIssueを長く使っていく
- 課題番号
