-Amazon.co.jp： 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化: David Farley, Jez Humble, 和智 右桂, 高木 正弘: 本
--http://www.amazon.co.jp/exec/obidos/ASIN/4048707876/nilabwiki-22/ref=nosim/
読書メモ
-nilog: Continuous Delivery 「いつまで手動でデプロイしているんですか？」信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 - 継続的デリバリー http://t.co/8S5GBIql84 (2013-09-10)
--http://www.nilab.info/nilog/?type=twitter&id=377190472948531200
--
-nilog: 新しい機能をインクリメンタルに開発し、定期的にこまめに trunk にコミット。チェックインするたびに自動テスト。マージが複雑にならないように。 - 継続的デリバリー http://t.co/4hQlAqcEo2 (2013-09-23)
--http://www.nilab.info/nilog/?type=twitter&id=382130500678066176
--
-nilog: テストダブル。 - 継続的デリバリー http://t.co/EgqvR2GnMR (2013-09-28)
--http://www.nilab.info/nilog/?type=twitter&id=383732669227352064
--
-nilog: 新機能は完成するまで隠す。UIをインクリメンタルに置き換える。 - 継続的デリバリー http://t.co/6CQsTKshzG (2013-09-28)
--http://www.nilab.info/nilog/?type=twitter&id=383733212121280513
--
書籍情報
-Amazon.co.jp： 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化: David Farley, Jez Humble, 和智 右桂, 高木 正弘: 本
--http://www.amazon.co.jp/exec/obidos/ASIN/4048707876/nilabwiki-22/ref=nosim/
-目次
--継続的デリバリーへの賛辞
--
--マーチン・ファウラーによるまえがき
--
--序文
--導入
--対象読者と扱っている内容
--概要
--本書内の Web リンク
--表紙について
--奥付
--
--謝辞
--
--著者について
--
--訳者紹介
--
--第1部 基礎
--
--第1章 ソフトウェアデリバリーの問題
--1.1 導入
--1.2 リリースによくあるアンチパターン
--1.2.1 アンチパターン：ソフトウェアを手作業でデプロイする
--1.2.2 アンチパターン：開発が終わってから擬似本番環境にデプロイする
--1.2.3 アンチパターン：本番環境について手作業で構成管理を行う
--1.3 もっとうまくできないのだろうか？
--1.4 どうすれば目標を達成できるだろうか？
--1.4.1 あらゆる変更はフィードバックプロセスを引き起こさなければならない
--1.4.2 フィードバックはできる限り早く受けとらなければならない
--1.4.3 デリバリーチームはフィードバックを受けとり、それに対応しなければならない
--1.4.4 このプロセスはスケールするのか？
--1.5 どんな恩恵を受けられるのか？
--1.5.1 チームに権限を与える
--1.5.2 エラーを削減する
--1.5.3 ストレスを低減する
--1.5.4 デプロイメントの柔軟性
--1.5.5 「できるようになりたければ、練習しろ」
--1.6 リリース候補
--1.6.1 あらゆるチェックインは潜在的にリリースにつながる
--1.7 ソフトウェアデリバリーの原則
--1.7.1 ソフトウェアをリリースするための、反復可能で信頼できるプロセスを作り上げよ
--1.7.2 ほとんどすべてを自動化せよ
--1.7.3 すべてバージョン管理に入れよ
--1.7.4 痛みを伴うものはこまめに実施し、痛い思いは早めにしておけ
--1.7.5 品質を作り込め
--1.7.6 完了したとはリリースしたということだ
--1.7.7 誰もがデリバリープロセスに対して責任を負う
--1.7.8 継続的改善
--1.8 まとめ
--
--第2章 構成管理
--2.1 導入
--2.2 バージョン管理を使う
--2.2.1 ひとつ残らずすべてバージョン管理に保存せよ
--2.2.2 定期的に trunk にチェックインせよ
--2.2.3 意味のあるコミットメッセージを使え
--2.3 依存関係の管理
--2.3.1 外部ライブラリを管理する
--2.3.2 コンポーネントを管理する
--2.4 ソフトウェア設定を管理する
--2.4.1 設定と柔軟性
--2.4.2 設定の種類
--2.4.3 アプリケーションの設定を管理する
--2.4.4 アプリケーションをまたいで設定を管理する
--2.4.5 アプリケーション構成管理の原則
--2.5 環境を管理する
--2.5.1 環境管理のためのツール
--2.5.2 変更プロセスを管理する
--2.6 まとめ
--
--第3章 継続的インテグレーション
--3.1 導入
--3.2 継続的インテグレーションを実現する
--3.2.1 始める前に必要なもの
--3.2.2 基本的な継続的インテグレーションシステム
--3.3 継続的インテグレーションの前提条件
--3.3.1 定期的にチェックインせよ
--3.3.2 包括的な自動テストスイートを作成せよ
--3.3.3 ビルドプロセスとテストプロセスを短く保て
--3.3.4 開発ワークスペースを管理する
--3.4 継続的インテグレーションソフトウェアを使用する
--3.4.1 基本的な操作
--3.4.2 オプション機能
--3.5 基本的なプラクティス
--3.5.1 ビルドが壊れているときにはチェックインするな
--3.5.2 コミットする前に、常にローカルでコミットテストを実行せよあるいは代わりにCIサーバーにやってもらえ
--3.5.3 次の作業を始める前に、コミットテストが通るまで待て
--3.5.4 ビルドが壊れているのに、家に帰ってはならない
--3.5.5 常に以前のリビジョンに戻す準備をしておくこと
--3.5.6 リバートする前にタイムボックスを切って修正する
--3.5.7 失敗したテストをコメントアウトするな
--3.5.8 自分が変更してビルドが壊れたら、すべてに対して責任をとれ
--3.5.9 テスト駆動開発
--3.6 やったほうがいいプラクティス
--3.6.1 エクストリームプログラミング (XP) の開発プラクティス
--3.6.2 アーキテクチャ上の違反事項があった場合にビルドを失敗させる
--3.6.3 テストが遅い場合にビルドを失敗させる
--3.6.4 警告やコードスタイルの違反があったときにビルドを失敗させる
--3.7 分散したチーム
--3.7.1 プロセスに与えるインパクト
--3.7.2 中央集権的継続的インテグレーション
--3.7.3 技術的な問題
--3.7.4 代替案
--3.8 分散バージョン管理システム
--3.9 まとめ
--
--第4章 テスト戦略を実装する
--4.1 導入
--4.2 テストの種類
--4.2.1 開発プロセスをサポートするビジネス視点のテスト
--4.2.2 受け入れテストを自動化する
--4.2.3 開発プロセスをサポートする技術視点のテスト
--4.2.4 プロジェクトの評価をするビジネス視点のテスト
--4.2.5 プロジェクトを評価する技術視点のテスト
--4.2.6 テストダブル
--4.3 実際に起こり得る状況と戦略
--4.3.1 新規プロジェクト
--4.3.2 プロジェクトの途中
--4.3.3 レガシーシステム
--4.3.4 インテグレーションテスト
--4.4 プロセス
--4.4.1 欠陥バックログを管理する
--4.5 まとめ
--
--第2部 デプロイメント パイプライン
--
--第5章 デプロイメントパイプラインの解剖学
--5.1 導入
--5.2 デプロイメントパイプラインとは何か？
--5.2.1 基本的なデプロイメントパイプライン
--5.3 デプロイメントパイプラインのプラクティス
--5.3.1 バイナリをビルドするのは1回限りとせよ
--5.3.2 あらゆる環境に対して同じやり方でデプロイせよ
--5.3.3 デプロイメントをスモークテストせよ
--5.3.4 本番のコピーにデプロイせよ
--5.3.5 各変更は直ちにパイプライン全体を通り抜けなければならない
--5.3.6 パイプラインのどの部分であっても、失敗したらラインを止めよ
--5.4 コミットステージ
--5.4.1 コミットステージのベストプラクティス
--5.5 自動受け入れテストという関門
--5.5.1 自動受け入れテストのベストプラクティス
--5.6 後に続くテストステージ
--5.6.1 手動テスト
--5.6.2 非機能のテスト
--5.7 リリースに備える
--5.7.1 デプロイメントとリリースを自動化する
--5.7.2 変更をバックアウトする
--5.7.3 成功を積み重ねる
--5.8 デプロイメントパイプラインを実装する
--5.8.1 バリューストリームをモデリングし、動くスケルトンを作成する
--5.8.2 ビルドとデプロイメントプロセスを自動化する
--5.8.3 ユニットテストとコード解析を自動化する
--5.8.4 受け入れテストを自動化する
--5.8.5 パイプラインを進化させる
--5.9 メトリクス
--5.10 まとめ
--
--第6章 ビルド・デプロイメントスクリプト
--6.1 導入
--6.2 ビルドツールの概要
--6.2.1 Make
--6.2.2 Ant
--6.2.3 NAnt と MSBuild
--6.2.4 Maven
--6.2.5 Rake
--6.2.6 Buildr
--6.2.7 Psake
--6.3 ビルドスクリプトとデプロイメントスクリプトの原則とプラクティス
--6.3.1 デプロイメントパイプラインのステージそれぞれに対してスクリプトを書け
--6.3.2 アプリケーションをデプロイするのに適切なテクノロジーを使え
--6.3.3 すべての環境にデプロイするのに、同じスクリプトを使え
--6.3.4 OS のパッケージングツールを使え
--6.3.5 デプロイメントプロセスが冪等であることを保証せよ
--6.3.6 デプロイメントシステムをインクリメンタルに進化させよ
--6.4 JVM を対象としたアプリケーションのためのプロジェクト構造
--6.4.1 プロジェクトのレイアウト
--6.4.2 ソースコードを管理する
--6.4.3 テストを管理する
--6.4.4 ビルドの成果物を管理する
--6.4.5 ライブラリを管理する
--6.5 デプロイメントスクリプト
--6.5.1 デプロイレイヤとテストレイヤ
--6.5.2 環境設定をテストする
--6.6 コツと裏技
--6.6.1 常に相対パスを使え
--6.6.2 手作業を根絶せよ
--6.6.3 バイナリからバージョン管理へのトレーサビリティを組み込め
--6.6.4 ビルド時にバイナリをバージョン管理にチェックインするな
--6.6.5 テストが失敗してもビルドは続けよ
--6.6.6 統合スモークテストでアプリケーションに制約をかけよ
--6.6.7 .NET のコツと裏技
--6.7 まとめ
--
--第7章 コミットステージ
--7.1 導入
--7.2 コミットステージの原則とプラクティス
--7.2.1 役に立つフィードバックを素早く提供せよ
--7.2.2 どういうときにコミットステージを止めるべきか？
--7.2.3 コミットステージを丁寧に整備せよ
--7.2.4 開発者に所有権を与えよ
--7.2.5 きわめて大規模なチームにはビルドマスターを置け
--7.3 コミットステージの結果
--7.3.1 成果物リポジトリ
--7.4 コミットテストスイートの原則とプラクティス
--7.4.1 ユーザーインターフェイスを避けよ
--7.4.2 DI を使用せよ
--7.4.3 データベースを避けよ
--7.4.4 ユニットテストでの非同期処理を避けよ
--7.4.5 テストダブルを利用する
--7.4.6 テスト内の状態を最低限に抑える
--7.4.7 時間の概念を偽装する
--7.4.8 しらみつぶし
--7.5 まとめ
--
--第8章 自動受け入れテスト
--8.1 導入
--8.2 なぜ自動受け入れテストが欠かせないのか？
--8.2.1 保守しやすい受け入れテストスイートの作り方
--8.2.2 GUI を叩いてテストする
--8.3 受け入れテストを作成する
--8.3.1 アナリストとテスターの役割
--8.3.2 イテレーティブなプロジェクトにおける分析
--8.3.3 実行可能な仕様としての受け入れ基準
--8.4 アプリケーションドライバレイヤ
--8.4.1 受け入れ基準の表現方法
--8.4.2 ウィンドウドライバパターン：テストとGUIを疎結合にする
--8.5 受け入れテストを実装する
--8.5.1 受け入れテストにおける状態
--8.5.2 プロセス境界・カプセル化・テスト
--8.5.3 非同期とタイムアウトを管理する
--8.5.4 テストダブルを利用する
--8.6 受け入れテストステージ
--8.6.1 受け入れテストをグリーンに保つ
--8.6.2 デプロイメントテスト
--8.7 受け入れテストのパフォーマンス
--8.7.1 共通のタスクはリファクタリングせよ
--8.7.2 高価なリソースは共有せよ
--8.7.3 並列テスト
--8.7.4 コンピュートグリッドを用いる
--8.8 まとめ
--
--第9章 非機能要件をテストする
--9.1 導入
--9.2 非機能用件を管理する
--9.2.1 非機能要件を分析する
--9.3 キャパシティを確保するためのプログラミング
--9.4 キャパシティを計測する
--9.4.1 キャパシティテストの成功・失敗の判断基準は？
--9.5 キャパシティテスト環境
--9.6 キャパシティテストを自動化する
--9.6.1 ユーザーインターフェイス経由のキャパシティテスト
--9.6.2 サービスや公開 API に対するインタラクションを記録する
--9.6.3 記録したインタラクションテンプレートを使う
--9.6.4 キャパシティテスト用スタブを使ったテスト作り
--9.7 キャパシティテストをデプロイメントパイプラインに追加する
--9.8 キャパシティテストシステムのもうひとつの利点
--9.9 まとめ
--
--第10章 アプリケーションをデプロイ・リリースする
--10.1 導入
--10.2 リリース戦略を作成する
--10.2.1 リリース計画
--10.2.2 製品をリリースする
--10.3 アプリケーションをデプロイする
--10.3.1 最初のデプロイメント
--10.3.2 リリースプロセスをモデル化し、ビルドを反映する
--10.3.3 設定を反映させる
--10.3.4 オーケストレーション
--10.3.5 ステージング環境へのデプロイメント
--10.4 デプロイメントのロールバック、そしてゼロダウンタイム・リリース
--10.4.1 直近の正常動作するバージョンの再デプロイメントによるロールバック
--10.4.2 ゼロダウンタイム・リリース
--10.4.3 ブルーグリーン・デプロイメント
--10.4.4 カナリアリリース
--10.5 緊急修正
--10.6 継続的デプロイメント
--10.6.1 ユーザーがインストールするソフトウェアを継続的にリリースする
--10.7 ヒントと裏技
--10.7.1 実際にデプロイメントを行う人たちを、デプロイメントプロセスの策定に参加させよ
--10.7.2 デプロイメント作業を記録せよ
--10.7.3 古いファイルは削除せず、移動せよ
--10.7.4 デプロイメントはチーム全体で責任を持つ
--10.7.5 サーバーアプリケーションに GUI を持たせない
--10.7.6 最初のデプロイメントにはウォームアップ期間を持たせよ
--10.7.7 失敗は早めに
--10.7.8 本番環境を直接修正するな
--10.8 まとめ
--
--第3部 デリバリー エコシステム
--
--第11章 基盤と環境を管理する
--11.1 導入
--11.2 運用チームのニーズを理解する
--11.2.1 文書化と監査
--11.2.2 異常発生時の警告
--11.2.3 IT サービスの継続計画
--11.2.4 運用チームが慣れている技術を使え
--11.3 基盤をモデリングし、管理する
--11.3.1 基盤へのアクセスを制御する
--11.3.2 基盤へ変更を加える
--11.4 サーバーのプロビジョニングおよび設定を管理する
--11.4.1 サーバーのプロビジョニング
--11.4.2 進行中のサーバー管理
--11.5 ミドルウェアの構成を管理する
--11.5.1 設定を管理する
--11.5.2 製品を調査せよ
--11.5.3 ミドルウェアが状態をどのように扱うのかを調査せよ
--11.5.4 設定 API を探せ
--11.5.5 よりよいテクノロジーを採用せよ
--11.6 基盤サービスを管理する
--11.6.1 マルチホームシステム
--11.7 仮想化
--11.7.1 仮想環境を管理する
--11.7.2 仮想環境とデプロイメントパイプライン
--11.7.3 仮想環境を使った、高度に並列化したテスト
--11.8 クラウドコンピューティング
--11.8.1 基盤のクラウド化
--11.8.2 プラットフォームのクラウド化
--11.8.3 ひとつで何もかもを解決する必要はない
--11.8.4 クラウドコンピューティングに対する批判
--11.9 基盤やアプリケーションを監視する
--11.9.1 データを収集する
--11.9.2 ログ出力
--11.9.3 ダッシュボードを作成する
--11.9.4 ふるまい駆動監視
--11.10 まとめ
--
--第12章 データを管理する
--12.1 導入
--12.2 データベースのスクリプト処理
--12.2.1 データベースを初期化する
--12.3 インクリメンタルな変更
--12.3.1 データベースのバージョンを管理する
--12.3.2 オーケストレイトされた変更を管理する
--12.4 データベースのロールバックとゼロダウンタイムリリース
--12.4.1 データを失なわずにロールバックする
--12.4.2 アプリケーションのデプロイをデータベースのマイグレーションから分離する
--12.5 テストデータを管理する
--12.5.1 仮のデータベースでのユニットテスト
--12.5.2 テストとデータのつながりを管理する
--12.5.3 テストの分離
--12.5.4 準備と後始末
--12.5.5 一貫したテストシナリオ
--12.6 データの管理とデプロイメントパイプライン
--12.6.1 コミットステージでのテストにおけるデータ
--12.6.2 受け入れテストにおけるデータ
--12.6.3 キャパシティテストにおけるデータ
--12.6.4 その他のテストステージにおけるデータ
--12.7 まとめ
--
--第13章 コンポーネントや依存関係を管理する
--13.1 導入
--13.2 アプリケーションをリリース可能な状態に保つ
--13.2.1 新機能は完成するまで隠せ
--13.2.2 すべての変更はインクリメンタルに
--13.2.3 抽象化によるブランチ
--13.3 依存関係
--13.3.1 依存地獄
--13.3.2 ライブラリを管理する
--13.4 コンポーネント
--13.4.1 コードベースをコンポーネントに分割する方法
--13.4.2 コンポーネントをパイプライン化する
--13.4.3 インテグレーションパイプライン
--13.5 依存グラフを管理する
--13.5.1 依存グラフを作成する
--13.5.2 依存グラフをパイプライン化する
--13.5.3 いつビルドすべきか？
--13.5.4 慎重な楽天主義
--13.5.5 循環依存
--13.6 バイナリを管理する
--13.6.1 成果物リポジトリの活用法
--13.6.2 デプロイメントパイプラインと成果物リポジトリとのやりとり
--13.7 Maven を使って依存関係を管理する
--13.7.1 Maven での依存関係のリファクタリング
--13.8 まとめ
--
--第14章 高度なバージョン管理
--14.1 導入
--14.2 リビジョン管理システムの簡単な歴史
--14.2.1 CVS
--14.2.2 Subversion
--14.2.3 商用のバージョン管理システム
--14.2.4 悲観的ロックをやめろ
--14.3 ブランチとマージ
--14.3.1 マージ
--14.3.2 ブランチ、ストリーム、そして継続的インテグレーション
--14.4 分散型バージョン管理システム
--14.4.1 分散型バージョン管理システムとは？
--14.4.2 分散型バージョン管理システムの簡単な歴史
--14.4.3 企業環境における分散型バージョン管理システム
--14.4.4 分散型バージョン管理システムを使う
--14.5 ストリームベースのバージョン管理システム
--14.5.1 ストリームベースのバージョン管理システムとは？
--14.5.2 ストリームを使った開発モデル
--14.5.3 静的ビューおよび動的ビュー
--14.5.4 ストリームベースのバージョン管理システムによる継続的インテグレーション
--14.6 メインライン上での開発
--14.6.1 複雑な変更をブランチなしで行なう
--14.7 リリース用のブランチ
--14.8 フィーチャによるブランチ
--14.9 チームによるブランチ
--14.10 まとめ
--
--第15章 継続的デリバリーを管理する
--15.1 導入
--15.2 構成管理およびリリース管理の成熟度モデル
--15.2.1 成熟度モデルの使い方
--15.3 プロジェクトのライフサイクル
--15.3.1 発見期
--15.3.2 開始期
--15.3.3 構築期
--15.3.4 開発・リリース期
--15.3.5 運用期
--15.4 リスク管理プロセス
--15.4.1 リスク管理入門
--15.4.2 リスク管理のタイムライン
--15.4.3 リスク管理の実践法
--15.5 デリバリーによくある問題――その症状と原因
--15.5.1 頻度の低いデプロイメント・バグのあるデプロイメント
--15.5.2 貧弱な品質のアプリケーション
--15.5.3 管理が貧弱な継続的インテグレーションプロセス
--15.5.4 貧弱な構成管理
--15.6 コンプライアンスと監査
--15.6.1 文書化よりも自動化を
--15.6.2 トレーサビリティを確保する
--15.6.3 サイロで作業する
--15.6.4 変更管理
--15.7 まとめ
--
--参考文献
--
--訳者あとがき
--謝辞
--
--索引