著者：池田 尚史
著者：藤倉 和明
著者：井上 史彰
シリーズ：WEB+DB PRESS plus
NDC：007.61 情報科学 >> データ処理．情報処理 >> システム分析．システム設計
チーム開発実践入門──共同作業を円滑に行うツール・メソッド：書籍案内｜技術評論社
本書はサービスやアプリケーションを開発する企業において，複数の人たちでチームを組んで開発を進めていく際に必要な考え方や使用するツール，またそれらをうまく使いこなすためのノウハウをまとめています。本書の最初でうまく物事が進んでいない開発現場の一例を示し，その理由と対策についてまとめています。次にその対策に必要なツールである，バージョン管理，チケット管理，CI（継続的インテグレーション），デプロイ，リグレッションテストの章を設け，その使い方と上手な運用ノウハウなどについて現場での経験が豊富な著者が解説しています。
【目次】
はじめに（著者を代表して 2014年3月 池田尚史） [iii-iv]
目次 [v-xvi]
第1章 チーム開発とは
1.1 1人だけでも開発はできる 002
1.2 チーム開発で直面する課題 003
1.3 どのように課題に立ち向かうか 004
1.4 本書の構成 005
第2章：ケーススタディ
第3～5章：基礎的なプラクティス
第6～7章：継続的デリバリーとリグレッションテスト
1.5 本書を読む前の注意点 007
最適なプラクティスはケースバイケース
どのツールを使うかに正解はない
第2章 チーム開発で起きる問題
2.1 ケーススタディの前提 010
プロジェクトの前提条件
2.2 ケーススタディ（1日目） 011
問題1：重要なメールが多すぎて優先順位を決められない
問題2：検証用環境がない
問題3：別名フォルダでブランチを管理している
問題4：データベースの再作成が困難
2.3 ケーススタディ（1日目）における問題点 016
問題1：重要なメールが多すぎて優先順位を決められない
メールの件数が多いために重要なメールが埋もれてしまう
ステータス管理ができない
一覧性，検索性が弱い
メールでプロジェクトを管理することの課題
問題2：検証用環境がない
問題3：別名フォルダでブランチを管理する
問題4：データベースの再作成が困難
2.4 ケーススタディ（2日目） 022
問題5：起動するまで壊れていることに気づかない
問題6：他メンバーの修正を上書きして消してしまう
問題7：自信を持ってリファクタリングできない
問題8：バグの修正時期がわからず，デグレードも追跡できない
問題9：ブランチ・タグを活用できていない
問題10：テスト環境や本番環境では動かない
問題11：リリースが複雑で手順書が必要となる
2.5 ケーススタディ（2日目）における問題点 031
問題5：起動するまで壊れていることに気づかない
問題6：他メンバーの修正を上書きして消してしまう
問題7：自信を持ってリファクタリングできない
問題8：バグの修正時期がわからず，デグレードも追跡できない
問題9：ブランチ・タグを活用できていない
問題10：テスト環境や本番環境では動かない
問題11：リリースが複雑で手順書が必要となる
2.6 理想的なプロジェクトとは 039
チケット管理システムに課題などが集約されている
できる限りバージョン管理システムを利用する
繰り返し再検証可能なCIシステムを用意する
環境の影響を最小限にとどめ，常にリリース可能にしておく
すべてを記録して追跡可能にする
2.7 本章のまとめ 042
第3章 バージョン管理
3.1 バージョン管理システム 044
バージョン管理システムとは
バージョン管理システムを使うとなぜ便利なのか
変更内容という最も基本的な記録が残る
バージョン間の差分を簡単に確認できる
間違って他人の変更を上書きしないで済むしくみがある
Column ロックモデルとマージモデル
任意の時点まで巻き戻すことができる
ファイルベースとチェンジセットベース
Column 複数の派生を作ることができる，ある時点での断面を保存できる
3.2 バージョン管理システムの移り変わり 053
バージョン管理システムがない時代（1970年代以前）
RCSの時代（1980年代）
CVSの登場（1990年代）
VSS，Perforceなど商用ツールの登場（1990年代）
Subversionの登場（2000年代）
分散バージョン管理システムの登場（2005年以降）
番外編：GitHubの登場
バージョン管理システムの導入状況
3.3 分散バージョン管理システム 062
分散バージョン管理システムを使うべき5つの理由
リポジトリの完全なコピーをローカルマシンに持つことができる
動作が速い
一時的な作業の履歴管理が容易である
ブランチ，マージが手軽にできる
場所を選ばないコラボレーションが可能
分散バージョン管理システムのデメリット
真の意味では最新バージョンはシステム上存在しない
真の意味ではリビジョン番号はない
ワークフローが柔軟に設定でき過ぎるため混乱しやすい
考え方に慣れるのに時間がかかる
3.4 バージョン管理システムをどう使うべきか 065
前提
バージョン管理システムで管理すべきもの
ソースコード
要件書，設計書などのドキュメント
データベーススキーマ・データ
設定ファイル
ライブラリなど依存関係定義
3.5 Gitを使ったスムーズな並行開発 069
ブランチの使い方
ブランチとは
リリースブランチとは
クローンとブランチの作成
コミットとコミットログ
ブランチの切り替え
バグ修正後のコミット
masterへのマージ
masterへのPush
ブランチの使い方のまとめ
タグの使い方
タグとは
タグの作成
タグの確認
タグの取得
Column タグ名とブランチ名を同一にするのを避ける
タグの使い方のまとめ
Column Detached HEADとは
3.6 Gitを使った開発フロー 081
Gitを使ったワークフローのパターン
中央集権型ワークフロー
GitHub型ワークフロー
ブランチ戦略のパターン
git-flow
github-flow
筆者の事例（折衷案）
最適なフローとブランチ戦略は現場によって異なる
3.7 データベーススキーマとデータの管理 090
データベーススキーマを管理する必要がある理由
データベース管理者の変更管理を任せた場合
共有データベースでスキーマを変更する場合
データベーススキーマをどのように管理すればよいか
バージョン管理に必要な要件
データベースマイグレーションとは
データベースマイグレーションの機能
データベースマイグレーションツール
Migration（Ruby on Rails）
south（Django）
Migrations Plugin（CakePHP）
Evolution（Play Framework）
具体的な使い方（Evolution）
規約
SQLファイルの適用
開発者間でのスキーマの同期
不整合の管理
データベースマイグレーションの注意点
3.8 設定ファイルの管理 102
3.9 依存関係の管理 103
依存関係解決システム
JVM系言語
スクリプト系言語
依存関係を管理するメリット
3.10 本章のまとめ 106
第4章 チケット管理
4.1 チケット管理システム 108
プロジェクトがうまく回らない理由
紙やメール，Excelでタスク管理をすることの問題点
チケット管理システムの導入メリット
タスク管理をするための基本機能がある
一覧性，検索性が高い
情報の一元管理と共有が可能である
レポーティングに利用できる
他システムとの連携が可能，拡張性がある
チケット駆動開発とは
チケット駆動開発の具体的手順
Column チケット駆動開発を徹底する場合
4.2 主なチケット管理システム 114
OSS製品
Trac
Redmine
Bugzilla
Mantis
商用製品
JIRA
YouTRACK
Pivotal Tracker
Backlog
GitHub
ツール選定のポイント
Column チケット管理システムの応用事例
4.3 チケット管理システムとバージョン管理システムの連携 124
連携によって実現する機能
コミットからチケットへのリンク
チケットからコミットへのリンク
コミットと同時にチケットのステータスを変更する
連携の設定方法
GitHub
GitHubのissue
Service Hooks
GitHubとPivotal Trackerの連携
GitHubとJIRAとの連携
Trac/Redmine
Backlog
BacklogのGitとの連携
BacklogとGitHubの連携
Git自身の用意するHookを使う方法
4.4 新機能の開発，バグの修正時のワークフロー 134
ワークフロー
①チケットの起票
②担当者のアサイン
③開発
④コミット
⑤リポジトリにプッシュ
4.5 「あのバグいつ直ったの」という問い合わせに答える 137
Pivotal Trackerの例
記憶に残っている文字列で検索
検索
チケットからソースコードの変更を探す
Backlogの例
検索
4.6 「なぜこんな変更が入ったんだろう」という疑問を解決する 142
4.7 本章のまとめ 143
チケット管理とバグ管理，要求管理について
第5章 CI（継続的インテグレーション）
5.1 CI（継続的インテグレーション） 148
CI（継続的インテグレーション）とは
インテグレーション
インテグレーションを継続的に行うのがCI
開発をアジャイル化する
ウォーターフォール開発の開発フェーズ
アジャイル開発の開発フェーズ
なぜCIのようなプラクティスが求められるか
コストメリット
市場の変化のスピード
スピードと品質を両立させるには
CIに必要なもの
バージョン管理システム
ビルドツール
テストコード
CIツール
テストを書くためのフレームワーク
テスト駆動開発（TDD）系フレームワーク
振る舞い駆動開発（BDD）系フレームワーク
主なCIツール
Jenkins
TravisCI
5.2 ビルドツールの使い方 164
新規にプロジェクトを始める場合
プロジェクトのひな型作成
依存関係の定義
テストの実行
Eclipseへのインポート
既存プロジェクトを自動ビルド可能にする場合
ビルドツールのまとめ
5.3 テストコードの書き方 172
CIの対象となるテストの種類
テストをいつ書くのか
新規にプロジェクトを始める場合
既存プロジェクトにテストがない場合
バグ修正または新機能を追加した場合
厄介なテストをどう書くか
外部とのやりとりがあるテスト
モッキングフレームワークを使ってテストする
インメモリデータベースを使ってテストする
データベース変更管理や設定ファイル管理のテスト
UIを伴うテスト
厄介なテストは工数とのトレードオフ
5.4 Jenkinsを使ったCIの実行 180
Jenkinsのセットアップ
ネイティブパッケージを使ったセットアップ
Jenkinsで何ができるのか
ジョブの新規作成
ソースコードをチェックアウトする
自動でビルドおよびテストを実行する
定期実行
バージョン管理システムをポーリング
バージョン管理システムからプッシュする
ビルドの記述
結果を集計してレポーティング
カバレッジを計測する
JUnitXML形式でレポートを出力するのが効率的
カバレッジ計測ツール
Maven Coberturaプラグインのインストール
Java系ライブラリの探し方
Jenkinsプラグインの設定
静的解析をする
通知の設定をする
5.5 CIの運用 197
ビルドが壊れたらどうするか
Subversionなど中央集権型バージョン管理システムの場合
Gitなど分散バージョン管理システムの場合
ビルドを壊したときの罰ゲーム
テストしてからマージする
トレーサビリティの担保
ビルドとコミットを関連づける
チケット管理と連携する
5.6 本章のまとめ―― CIによって得られるもの 208
第6章 デプロイの自動化（継続的デリバリー）
6.1 デプロイとはどうあるべきか 210
デプロイの自動化における恩恵
細かくたくさんリリースできればリスクをコントロールしやすくなる
フィードバックを早く得られるようになる
組織がスケールする
6.2 デプロイの自動化 212
デプロイの自動化における共通認識
デプロイメントパイプライン
自動化によりデプロイの速度を加速させる
誰でもデプロイが行えるようにすることが重要
プロビジョニングツールチェーン
6.3 ブートストラッピング（Bootstrapping） 216
Kickstart
Kickstartの利用方法
利用する際の注意点
Kickstartの設定例
Vagrant
開発者ごとに実機を用意することは難しい
仮想環境を利用する際の懸念点
Vagrantとは
Vagrantのインストールと実行方法
6.4 コンフィグレーション（Configuration） 222
自動化を行わない場合の問題点
Chef
Chefの構成
ディレクトリ構成とファイル配置
node.json
setup.json
solo.rb
default.rb
virtualhost.conf.erb
Chefの実行方法と実行結果
Chefを利用するメリット
Chefを利用する際の注意点
Chefを利用するタイミング
serverspec
serverspecとは
serverspecのインストール
テストファイルの記述方法
httpd_spec.rb
git_spec.rb
serverspecの実行方法と実行結果
serverspecのメリット
ベストプラクティス（その1）
Vagrantfile
default.rb
ベストプラクティス（その2）
物理サーバがサービス投入可能になるまでの流れを自動化する例
リリース作業についてのアンチパターン
6.5 オーケストレーション（Orchestration） 239
Capistrano
Capistranoのシステム構成
Capistranoのインストール
deploy.rb
Capistranoの実行方法
Fabric
Fabric（直列実行）の場合
Capistrano（並列実行）の場合
ローカルサーバとリモートサーバの操作の違いを理解する
Fabricの実行方法
Jenkins
マスタノードとスレーブノードの連携
スレーブノードの追加
ジョブの追加
ジョブの実行
ベストプラクティス
JenkinsとFabricを組み合わせる
セキュリティについて考慮する
Column 手作業でデプロイするケース
6.6 運用について考慮する 256
サービスを止めないデプロイ方法
ブルーグリーンデプロイメント
クラウド時代のブルーグリーンデプロイメント
ロールバックについての考察
退路は常に用意する
データベーススキーマのバージョン管理
ロールバックの検証
ソース更新のみのリリース時のロールバック
データベーススキーマ更新時のロールバック
6.7 本章のまとめ 265
PaaSを利用する手段
第7章 リグレッションテスト
7.1 リグレッションテスト 270
リグレッションテストとは
テスト種別の整理
チームを支援する技術面のテスト（第1象限）
チームを支援するビジネス面のテスト（第2象限）
製品を批評するビジネス面のテスト（第3象限）
技術面のテストを使った製品の批評（第4象限）
リグレッションテストの必要性
デグレードの発生
テストを自動化すべき理由
リグレッションテストの自動化で目指すこと
7.2 Selenium 277
Seleniumとは
Seleniumの利点
自動化テストケース作成が簡単
多くのブラウザやOSをサポート
Seleniumコンポーネント
Selenium IDE
Selenium Remote Control（Selenium RC）
Selenium WebDriver
テストケースの作成と実行
Selenium IDEのインストールと実行
Seleniumのテストケース
良いテストケースとは
Selenium Serverを使ったテスト実行
Seleniumの実践活用
画面が変更されていないかをテストする
Seleniumテストを安定させるためには
7.3 JenkinsとSeleniumの連携 294
JenkinsとSeleniumの連携手順
7.4 Seleniumテストの高速化 299
Jenkinsの分散ビルドでテストの並列実行
Jenkinsの分散ビルドの構成
分散ビルドの設定
Seleniumテスト並列化の難しさ
7.5 複数のアプリケーションバージョンでのテスト 306
アプリケーションのデプロイ
テストケースをバージョン管理システムからチェックアウト
Seleniumでのテスト
7.6 本章のまとめ 309
参考文献・参考URL [310-311]
索引 [312-318]
著者プロフィール [319]
