Recommended
More Related Content
What's hot
What's hot (20)
Similar to 「チーム開発実践入門」勉強会
Similar to 「チーム開発実践入門」勉強会 (20)
More from Yu Ishikawa
More from Yu Ishikawa (10)
Recently uploaded
Recently uploaded (10)
「チーム開発実践入門」勉強会
- 2. + 知っている単語はいくつありますか？ – 単体テスト or TDD (Test Driven Development) – 継続的インテグレーション – 継続的デリバリー – Git – Jenkins
- 3. + タイトル：チーム開発実践入 門 + 発行所：技術評論社 + 内容：“複数の人たちでチーム を組んで開発を進めていく際 に必要な考え方や使用する ツール、またそれらをうまく 使いこなすためのノウハウを まとめて”ある
- 5. + チーム開発に役立つツールや方法論に唯 一絶対の正解はありません + 企業規模，製品規模，チーム規模によっ て最適な解決策はことなります + しかし，紹介する内容には，効率的に仕 事をする上で様々なヒントを与えてくれ ると思います
- 6. + ケーススタディ + バージョン管理 + チケット管理 + （５〜10分休憩） + 継続的インテグレーション + 継続的デリバリー + まとめ
- 7. + ケーススタディ + バージョン管理 + チケット管理 + 継続的インテグレーション + 継続的デリバリー + まとめ
- 8. + デスマーチになっている Web アプリ開発 プロジェクトに途中でアサインされた A さんの話 + プロジェクトの前提 – システム Web アプリケーション DB – 開発のみならずリリース後のバージョンアッ プや運用なども継続的に行う
- 10. + １日目重たい気持ちで出社したAさんが早速メールを開 くとつぎのような４件のメールが… – 【重要】エラーが出ています．すぐに対応してください！ – 【至急】本番環境で重大な障害が発生！対応お願いします – 【依頼】軽微のレイアウトズレが起きているようです – 【本番障害】【重要】【至急】【即対応】お客様からクレームを頂いています． いますぐ対応してください + しかし，アサインされたばかりのAさんどれから対応す べきかの優先度が付けられません + 周りの人に聞きつつ，全部読んで対応することにします
- 11. + 報告されたエラーが本当に発生するのかを試そうとしま すが，本番での検証をするのには重大な障害もありまし た + しかし検証環境がないためすぐに試すことができません + しかたがないので，手元の自分のマシンに検証用の環境 を構築することにしました + 残念ながら，環境を構築するための手順がまとまってい ません！ + しかたがないのでほかのメンバーにひとつひとつ聞きな がら構築します
- 12. + なんとかサーバ構築が終わり，要約アプリのソースコー ドとDBの構築をしようとします + ソースコードがディレクトリ名を変えることで管理され ているため，いま本番で動いているのがどのソースコー ドなのかわかりません – app_latest – app_new – app_current – app_lastest2 + DB の構築を試みるもスキーマが管理されていないので， 本番サーバのスキーマを調べて自分で再構築しました + アプリの起動とDBの構築が終わるもうまく再現するこ とができません
- 13. + ようやく本番と「同じと思われる」環境を構築して，バ グの修正に入ります + Aさん一人では対応できないので，それぞれ４件のバグ を４人で手分けして行うことにしました + 急いで対応している中，バグ報告者から電話での状況確 認の問い合わせが頻繁に来て，作業に集中できません + なんとか，それぞれの環境でなんとか各自担当したエ ラーを修正して，手作業で再現しないことを確認し，共 有フォルダに各自同期をとって１日目を終えました
- 14. + ２日目の朝，テスト担当者からAさんに４件の修正のう ち３件しか直っておらず，昔直したはずのバグも発生し ているという連絡が入りました + 調べてみると，４件のバグで手分けした修正でお互いの 変更を上書きしてしまったようでした + またテスト担当者の環境とAさんの環境が違うため発生 している問題もあったようです + 問題の箇所を修正しなおし，１日目に報告されたバグの 対応を終えました
- 15. + 昔直されたバグについての修正をしようとします + しかし，途中からアサインされたAさんには昔どのよう なやりとりがなされて，どのように修正されたのかを メールでタスク管理されていたため追跡することができ ません + ほかの人に調べてもらい，どういう経緯かの把握をすま せ，要約バグ対応に入ります + まずバグが再現するのかを手元のマシンで確認をし， ソースコードのどこに問題があるのか調査をはじめます + ソースコードがバージョン管理されていないので昔の修 正を確認することができないため，自分なりに変更を加 えバグが再現しないことを確認しました
- 16. + なんとかテストもクリアし，修正したものをリリースし ます + いつもリリースしている人が休みなので，手順書にした がって手作業で行います + ソースコードのデプロイだけでなく，DDLや依存するラ イブラリ，設定ファイルの反映など複雑なようです + リリースしてみるも，作業にもんだいがあったのか本番 環境にうまく反映することができません + デプロイする前の状態に戻すやり方がわかりません + 参考にしている手順書のバージョンが古かったらしく， なんとか最新の手順書を確認しながら無事リリースがで きました
- 18. + メールでのタスク管理 – タスクの優先順位がわからないため，どれから対応すべきかが わからない – タスクのステータス管理ができないため，いちいち問い合わせ に対応しないといけない – ほかのメールと交じるため一覧性が悪い – 途中から加わったメンバーが過去の状況を確認できないなど検 索性が悪い + 検証環境（ステージング環境）がない – 報告されたバグを速やかに検証する環境がないため，ことある ごとに手元に環境を構築する必要がある + メンバーそれぞれがバラバラに環境を構築している – 統一した環境を構築する仕組みが無いために，お互いの環境を 都度揃えるためのコストがかかる
- 19. + ソースコードがバージョン管理されていない – 互いの変更を上書きしてしまう – お互いの差分が衝突したときの解決ができない – 過去のバグ修正の履歴が負えない + DBの再生成が困難 – アプリを起動するために必要な DDL やデータがきちんと管理さ れていないため，都度本番のデータをダンプして持ってくるな どの無駄が発生 + 自動テストがないためデグレーションを検知できない – 既存の昨日に影響を与えていないかなどのチェックを手作業でやったりしてい ると，抜け漏れが発生するし，コストが高い
- 20. + リリース手順が手作業あるいは複雑 – リリース作業を手作業でやるとそのための修 正コスト，メンテナンスコストが高くなる + 本番環境で動かない – 設定の反映を間違えるなどにより，本番で動 かないリスクが伴う
- 22. + タスクの管理は，タスク管理用ツールを活用されている – バグ報告者はタスクのステータスを確認することで問い合わせコストがなくな るなど + ナレッジは wiki にまとまっている – 新しいメンバーも簡単に検索することができて，スムーズにプロ ジェクトに必要な知識を身につけられる – ひとの時間を奪わない + 検証環境が用意されている – 報告されたバグをすみやかに再現できる + 確認作業，テストがすべて自動化されている + 各自の環境を自動的に整える仕組みがある – 各自の環境が異なっているために起きる問題がない + ソースコードは適切にバージョン管理されている – 過去の履歴を追跡できる – 互いに上書きするリスクを抑えられる + 自動的にリリースする仕組みがある – 間違えたり忘れたり，また属人性を排除するために手作業はなくす
- 23. + 自動化 + 追跡可能性 + 再現性 + {属人性,暗黙知}の排除 + 人間は間違えかつ忘れる
- 24. + ケーススタディ + バージョン管理 + チケット管理 + 継続的インテグレーション + 継続的デリバリー + まとめ
- 25. + あるファイルをいつ，だれが，なにを，どのよう に変更したかの履歴を記録として管理するシステ ム + 導入メリット – 変更内容という最も基本的な記録が残る – バージョン間の差分が簡単に確認できる – 間違って他の人の変更を上書きしないで住む仕組み がある – 任意の時点まで巻き戻すことができる + ツール例（SVN の時代は終了しました） – Git（分散管理）, Github などが有名 – SVN: Subversion （中央管理）
- 28. + 「管理できるものはすべて VCS で管理すべき」 – ソースコード – テストコード – 要件書，設計書などのドキュメント – データベーススキーマ，システムを構築するのに必要な データ – ミドルウェアなどの設定ファイル – ライブラリなどの依存関係の定義 + 注意：VCS 管理者によっては Excel などの バイナリファイルはコミットされたくない人 もいるのでルールに合わせる
- 29. + 一時的な作業の履歴管理が容易 – 中央管理型と異なり，全体に影響を与えないままローカルマシ ンでのコミットをすることが可能なため，一時的な作業の保存 も容易で開発効率が向上 + 場所を選ばないコラボレーションが可能 – すべてのコピーをローカルマシンに持つため，リポジトリと ネットワーク通信ができない環境でもローカルマシンにコミッ トを残せる
- 30. + バージョン管理システムのモデル – ロックモデル – マージモデル + バージョン管理システムの移り変わり + Git を使ったスムーズな並行開発 + Git を使った開発フロー
- 31. + ソースコードと異なる管理の難しさ – 複数人でDB変更を行うと，SQLの適応漏れや順 番の違いなどによって容易にDBの整合性が損な われる可能性 + 考えつく案 – データベース管理者に変更管理を任せる 作業のボトルネックになってスピードが損なわれる 属人性が高くなる – 共有データベースでスキーマを変更する場合 開発のために変更を加えるとほかの人に影響
- 32. + データベースの変更を管理するツール + ツールの発想 – SQL の適用順とどこまで適用したかを管理 – スキーマ定義編集の衝突を管理 – ロールバックの仕組みを用意 – データのロードもできる + 具体的なツール例 – Migration: Ruby on Rails – south: Django – Migrations Plugin: CakePHP – Evollution – Play Framework
- 33. 1.sql 2.sql • 適応順をファイル名で管理 • ロールバックのための処理と アノテーション
- 34. + 構築された DB は本当に正しいでしょう か？ + 正しいかどうかを自分で手作業で確認し ますか？ + NO：DB 整合性チェクは自動で行えます
- 35. + 設定ファイルもバージョン管理 – すべてがバージョン管理システムにあって，そこにある ファイルだけでアプリケーションの構築から起動まで，い つでもだれでも自動でできるようにしておかないと，高い 品質とスピードを維持した開発はできない + 依存関係解決システム – ある程度の規模のアプリケーション開発をするときは，何 らかのライブラリを利用 – アプリケーションが管理している依存関係の定義もバー ジョン管理 – 依存関係解決システム Apache Ant (Apache Ivy) Maven Sbt Gradle
- 36. + 「管理できるものはすべて VCS で管理すべき」 + 使うなら SVN じゃなくて Git – Git の運用方法に興味ある人は本読んで下さい – Github を試してみてください + 自動化のためのツールを活用 – DB のバージョンごとの管理には，データベースマイ グレーションツールがある – 依存関係解決システムで，プロジェクトに必要なラ イブラリを管理 – サーバ構築やプロビジョニングの話は後ほど
- 37. + ケーススタディ + バージョン管理 + チケット管理 + 継続的インテグレーション + 継続的デリバリー + まとめ
- 38. + プロジェクトの見える化 + タスクの整理，進捗の管理，情報の共有 – タスクの定義：なにをするのか？ – 期限：いつまでにするのか？ – 担当者：だれがするのか？ – ステータス：いまどうなっているのか？ + 情報の一元管理と検索性が重要
- 39. + 代替はできるが，人数が多くなって，タスクが増 えると破綻する + メールで管理 – 途中からアサインされた人は過去の情報がわからな い – ほかのメールに埋もれる – ステータスがわからない – 担当者がわからない + 共有フォルダで管理 – 複数に編集でファイルが壊れる可能性 – だれかが誤って削除する可能性 – 検索性が低いためドキュメントを探しにくい
- 41. + タスクを管理するための基本機能がある – 「なにをしなければいけないのか」というタスクの定義 – 「誰がするのか」という担当者のアサイン – 「いつまでにするのか」という期限の管理 – 「いまどうなっているのか」というステータスの管理 + 一覧性，検索性が高い + 情報の一元管理と共有が可能 – 過去のやりとりやそこから得られた知見，プログラムの仕様 – タスク管理だけでなく，ナレッジデータベースとしての側面も持てる + レポーティングに利用できる – バーンダウンチャートなどのレポーティング機能 + ほかのシステムとの連携が可能であり，拡張性を高める – バージョン管理システムや Continuous Integration システムとの連携を深めることで， 問題の発生からコードの修正内容やテスト結果，リリース状況まですべてを関連付け て管理することができる + 追跡可能性が高まる – 例：「昔のバグ修正ってどういう経緯だったけ？」 – 例：チケットIDとバージョン管理の関連付け
- 43. + OSS – Trac – Redmine – Bugzilla + 商用 – JIRA 個人のプライベートタスクにも便利 クラウド版は 10 Users $10/month – Backlog – Github + ツール選定のポイント – 拡張性の高さと容易さがどこまで提供されているか – エンジニア以外のステークホルダーも触れるので，業務フロー に合わせて柔軟に拡張できるかが重要
- 44. + チームのプロジェクト管理だけでなく，他部署への作業 依頼 – 「サーバにこのソフトウェアをインストールしてください」 – 「こことあそこの通信の疎通をしてください」 + カスタマーサポートの管理
- 45. + メールやエクセルでの管理はやめましょう + タスク管理ツールと wiki を使って，タスクと情 報共有を一元管理しましょう + チケット駆動開発という方法もあります
- 47. + ケーススタディ + バージョン管理 + チケット管理 + 継続的インテグレーション + 継続的デリバリー + まとめ
- 48. + 各人のソースコード成果物を１箇所に集める + 依存するライブラリなどを解決 + 必要であればコンパイル + データベースの構築と必要なデータのロード + 必要であればミドルウェアの設定や起動 + 単体テストと結合テスト，ユーザ受け入れテス トなどを実施
- 49. + インテグレーションを絶え間なく短時間で自動的 に実行できる仕組み + メリット – ソースコードの修正をコミットしたすぐに問題ない かどうかを調べることができる + アジャイル開発手法の１つであるエクストリーム プログラミング（XP）のプラクティスとして提唱 + 価値のあるソフトウェアを高品質かつ迅速に提供 することを目指すアジャイル開発の中でも，最も 基本的で重要なプラクティス
- 51. レビュー 開発 ２週間 レビュー 開発 ２週間 レビュー 開発 ２週間 • 短い期間で要件自体の修正，要件とのズレを検出し調整できる • アジャイルを実施するためには継続的インテグレーションが必要
- 52. + ウォーターフォール – インテグレーションは開発作業がすべて完了したあとのテスト フェースに入って初めて行う – テストフェーズになって，ライブラリの漏れやコンパイルができな いなどの問題が発生 – コード量が増えれば増えるほど，修正が困難になる – プロジェクト終盤になってすべてやり直しになるリスクがある + Scrum（アジャイル開発） – スプリントという２週間程度の短いサイクルで設計開発と単体テス ト，結合テスト，ユーザ受け入れテストを複数回実施 – スプリントごとに成果物を出し，スプリントレビューというプロセ スで成果物をレビュー，フィードバックし，つぎのスプリントに反 映するということを繰り返す – 要件の変更への柔軟な対応やズレをできるだけ早く検出して調整す る回数を増やしていこうというアプローチ
- 53. + コストメリット – バグの修正コストはバグが生み出された瞬間から時 間が経過するごとに増加していく – テストをせずに，昨日生み出されたバグより３ヶ月 たったバグを修正するのは困難 – ビルドとテストを自動化して，CI を実施できればコ ミット後にバグの発生に気づける + 市場の変化のスピード – １つの製品に１年も２年もかけていたら市場が変化 してしまい，リリースしたころには市場にマッチし ない可能性 – たとえ会計システムのような業務システムでも，急 な法改正などで外的環境が変化
- 54. + ソースコード + テストコード + バージョン管理システム – Git + ビルドツール – Maven – Sbt – Gradle + CI ツール – Jenkins CIツールのデファクトスタンダード – TravisCI Github のプロジェクトのみ利用可能
- 55. + ソフトウェアのビルドやcronで起動するジョブ などの繰り返しのジョブの実行を監視 – 継続的なソフトウェアプロジェクトのビルドとテス ト ソースコードのデプロイもできる – 外部で起動するジョブの実行監視
- 58. + なんのためにテストを書くのか？ – 機能を担保するため – のちのち修正変更をしやすくするため – 自分を守るため + 単体テストの種類 – TDD (Test Driven Development) – BDD (Behavior Driven Development)
- 59. + テストと開発を平行して実施 public class User { } @RunWith(JUnit4.class) public class UserTest { } ソースコード テストコード
- 60. + 失敗する機能要件のテストを書く public class User { } @RunWith(JUnit4.class) public class UserTest { @Test public void testCreateInstance() { User bob = new User(“Bob”); } } ソースコード テストコード
- 61. + テストをクリアするコードを書く public class User { private String name; public User(String name) { this.name = name; } } @RunWith(JUnit4.class) public class UserTest { @Test public void testCreateInstance() { User bob = new User(“Bob”); } } ソースコード テストコード
- 62. + 失敗する機能要件のテストを書く public class User { private String name; public User(String name) { this.name = name; } } @RunWith(JUnit4.class) public class UserTest { @Test public void testCreateInstance() { User bob = new User(“Bob”); } @Test public void testGetName() { User bob = new User(“Bob”); assertEquals(“Bob”,bob.getName() ); } } ソースコード テストコード
- 63. + テストをクリアするコードを書く public class User { private String name; public User(String name) { this.name = name; } public String getName() { return this.name; } } @RunWith(JUnit4.class) public class UserTest { @Test public void testCreateInstance() { User bob = new User(“Bob”); } @Test public void testGetName() { User bob = new User(“Bob”); assertEquals(“Bob”,bob.getName() ); } } ソースコード テストコード
- 65. + 常にビルド，常にテストを回すことで，加え た修正それ自体が問題ないか，既存の機能を 壊していないかをすぐに知れる – 要件定義・開発からテストまどの期間が長くなれ ばなるほど，修正・変更コストが増大 + CIツールを導入することで，ビルドやテスト に問題が発生したときに追跡可能 + Jenkins がデファクトスタンダード + TDDは楽しいし，コードの問題点を局所的に できる
- 66. + ケーススタディ + バージョン管理 + チケット管理 + 継続的インテグレーション + 継続的デリバリー + まとめ
- 67. + 「デプロイに関わる作業はすべて自動化すべきである」 – デプロイ：開発したソースコードを利用可能な状態でサーバに 配布する一連の行為 + コミットして問題なければ自動的にデプロイ + ポチッと１クリックでだれでも簡単にデプロイ + とにかく，だれでも簡単にデプロイできることが重要！
- 68. + 細かく頻繁にデプロイできればリスクをコントロールしやす くなる – 何ヶ月に１回の大きな変更のデプロイをすると，不具合が起きた時 の被害をコントロールするのが難しくなる – こまめに変更をデプロイすることで，不具合の規模感をコントロー ルできる + フィードバックを早く得られる – 新しく開発した機能をいちはやく試してもらい，そのフィードバッ クをつぎの開発サイクルに反映 – 短期間のPDCA サイクルを実現 + 組織がスケールする – たとえば 10 個のプロダクトがあり，10 通りのデプロイ方法を手動 で延々と行い続けるのは得策ではない – だれでも簡単にデプロイできるようにすることでメンテナンスコス トを低くし，新しいことにチャレンジしていける組織になれる – 属人性の排除
- 69. + プロビジョニング – 利用可能なサーバに、適切なOS, ミドルウェア，アプリケー ションをロードし、システムを適切に設定したり、サーバ固有 の設定（IPアドレスなど）をしたり、といった作業 + プロビジョニングツールチェーン – ブートストラッピング サーバの OS 設定や仮想マシンによるサーバ立ち上げの自動化ツール – コンフィギュレーション サーバやミドルウェアの設定の自動化ツール – オーケストレーション ソースコードのデプロイやリリースに関わるサーバの操作の自動化ツール
- 70. + Vagrant – 仮想マシン作成やその環境設定などを自動化するツール + Chef – 物理、仮想、クラウドといったさまざまな大きさのインフラに対して、 サーバやアプリケーションの展開を容易にするための自動化フレーム ワーク – 自動でミドルウェアをインストールするためのツール + Serverspec – サーバの状態をテストするためのフレームワーク + サーバ構築要件 – CentOS 6.5 – MySQL 5.1, Apache 2.3 – Port は 80 を開ける
- 71. Vagrantfile Chef cookbook specfile CentOS6.5 で 仮想マシンの作成 Vagrant Chef MySQL 5.1, Apache 2.3 のインストール serverspec 80 番ポート開いてる？ MySQL 5.1 入ってる？ Apache 2.3 入ってる？
- 73. + 「デプロイに関わる作業はすべて自動化すべきである」 – {開発,ビルド}環境の構築 – ビルド – テスト環境の構築 – テスト – リリース – コンフィギュレーション + モダンな開発では環境構築やサーバ構築テストも自動化 – Vagrant + Chef + serverspec
- 74. + ケーススタディ + バージョン管理 + チケット管理 + 継続的インテグレーション + 継続的デリバリー + まとめ
- 76. + タスクの管理は，タスク管理用ツールを活用されている – バグ報告者はタスクのステータスを確認することで問い合わせコストがなくな るなど + ナレッジは wiki にまとまっている – 新しいメンバーも簡単に検索することができて，スムーズにプロ ジェクトに必要な知識を身につけられる – ひとの時間を奪わない + 検証環境が用意されている – 報告されたバグをすみやかに再現できる + 確認作業，テストがすべて自動化されている + 各自の環境を自動的に整える仕組みがある – 各自の環境が異なっているために起きる問題がない + ソースコードは適切にバージョン管理されている – 過去の履歴を追跡できる – 互いに上書きするリスクを抑えられる + 自動的にリリースする仕組みがある – 間違えたり忘れたり，また属人性を排除するために手作業はなくす
- 77. バグ報告者 ほかの開発者 タスクは タスク管理ツール で管理 業務知識は Wiki に一元管理 各自の開発環境は 自動プロビジョニン グで統一 Git による適切な バージョン管理 ビルド，テスト リリースなどデプロイ の自動化 ステージング環境 （自動構築） 継続的 インテグレーション 継続的デリバリー 本番環境 リリース
- 79. + 自動化 + 追跡可能性 + 再現性 + {属人性,暗黙知}の排除 + 人間は間違えかつ忘れる