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