入門 継続的デリバリー

序文
はじめに

第1部　継続的デリバリーとは

1章　『入門 継続的デリバリー』へようこそ
    1.1　継続的デリバリーは必要？
    1.2　なぜ継続的デリバリー？
    1.3　継続的デリバリーとは
    1.4　インテグレーション
    1.5　継続的インテグレーション
    1.6　何をデリバリーするのか？
    1.7　デリバリー
    1.8　継続的デリバリーと継続的デプロイメント
    1.9　継続的デリバリーの要素
    1.10　総括
    1.11　まとめ

2章　パイプラインの基本
    2.1　Cat Picture Website
    2.2　Cat Picture Websiteのソースコード
    2.3　Cat Picture Websiteのパイプライン
    2.4　パイプラインとは何か、タスクとは何か
    2.5　CDパイプラインの基本タスク
    2.6　ゲートとトランスフォーメーション
    2.7　CDにおけるゲートとトランスフォーメーション
    2.8　Cat Picture Websiteのサービスパイプライン
    2.9　パイプラインの実行
    2.10　1日1回実行する
    2.11　継続的インテグレーションを試してみる
    2.12　通知を利用する
    2.13　手作業のボトルネックを解消する努力
    2.14　Webhookによる自動化
    2.15　Webhookで起きた変化
    2.16　壊れているときは変更をプッシュしない
    2.17　Cat Picture Website CD
    2.18　名前の中身は？
    2.19　総括
    2.20　まとめ

第2部　常にデリバリー可能な状態に保つ

3章　バージョン管理は継続的デリバリーの成功に不可欠
    3.1　サーシャとサラのスタートアップ
    3.2　すべての種類のデータ
    3.3　ソースコードとソフトウェア
    3.4　リポジトリとバージョン
    3.5　継続的デリバリーとバージョン管理
    3.6　GitとGitHub
    3.7　最初のコミット（バグ付き！）
    3.8　mainブランチの破壊
    3.9　プッシュとプル
    3.10　継続的デリバリーをしているか？
    3.11　バージョン管理をリリース可能な状態に保つ
    3.12　バージョン管理への変更をトリガーする
    3.13　Userサービスのパイプラインをトリガーする
    3.14　Userサービスのビルド
    3.15　クラウド上のUserサービス
    3.16　RandomCloudデータベースへの接続
    3.17　Userサービスの管理
    3.18　Userサービスの障害
    3.19　自動化の裏切り
    3.20　Source of Truthって何？
    3.21　UserサービスのConfig as Code
    3.22　Deployakerの設定
    3.23　Config
    3.24　ソフトウェアと設定の変更のロールアウト
    3.25　総括
    3.26　まとめ

4章　リントを効果的に使う
    4.1　ベッキーとスーパーゲームコンソール
    4.2　リントで解決！
    4.3　リントの基礎知識
    4.4　Pylintの話と、いろいろな問題の話
    4.5　レガシーコード：体系的なアプローチ
    4.6　ステップ1：コーディング規約に反する設定
    4.7　ステップ2：ベースラインの設定
    4.8　ステップ3：投稿時の強制
    4.9　パイプラインに強制力を持たせる
    4.10　ステップ4：分割して乗り越える
    4.11　隔離：すべてを修正すべきではない
    4.12　隔離の強制
    4.13　すべての問題が同じように作られているわけではない
    4.14　リントの問題の種類
    4.15　バグが先、スタイルは後
    4.16　難題を乗り越える
    4.17　総括
    4.18　まとめ

5章　ノイズの多いテストに対処する
    5.1　継続的デリバリーとテスト
    5.2　Ice Cream for Allの障害
    5.3　シグナル vs ノイズ
    5.4　ノイズになる成功
    5.5　どのように失敗がノイズになるのか
    5.6　ノイズからシグナルへ
    5.7　グリーンな状態への道筋
    5.8　また障害！
    5.9　テストの成功もノイズになる
    5.10　テストの失敗を修正する
    5.11　失敗の原因：フレーキーテスト
    5.12　失敗への対応
    5.13　テストの修正：コードを変えるか、テストを変えるか？
    5.14　再試行の危険性
    5.15　再試行についての再検討
    5.16　なぜ再試行するか
    5.17　グリーンな状態にして、グリーンな状態を保つ
    5.18　総括
    5.19　まとめ

6章　遅いテストスイートを速くする
    6.1　Dog Picture Website
    6.2　シンプルがシンプルすぎるとき
    6.3　新人エンジニアがコードのサブミットに挑戦
    6.4　テストと継続的デリバリー
    6.5　診断：遅すぎる
    6.6　テストピラミッド
    6.7　速いテストから先に
    6.8　2つのパイプライン
    6.9　正しいバランスを得るために
    6.10　ピラミッドの変化
    6.11　テストの安全な調整
    6.12　テストカバレッジ
    6.13　テストカバレッジの強制
    6.14　パイプラインでのテストカバレッジ
    6.15　カバレッジのピラミッドにおけるテストの移動
    6.16　ピラミッドの下に移動するには？
    6.17　レガシーテストとFUD
    6.18　テストの並列実行
    6.19　並列実行できるのはどのようなテスト？
    6.20　パイプラインの更新
    6.21　まだ遅すぎる！
    6.22　テストのシャーディング
    6.23　シャーディングの方法
    6.24　より複雑なシャーディング
    6.25　シャーディングされたパイプライン
    6.26　ブラウザテストのシャーディング
    6.27　パイプラインでのシャーディング
    6.28　Dog Picture Websiteのパイプライン
    6.29　総括
    6.30　まとめ

7章　適切なタイミングで適切なシグナルを送る
    7.1　CoinExCompare
    7.2　変更のライフサイクル
    7.3　マージ前のみのCI
    7.4　変更におけるバグ発生の時系列
    7.5　マージ前のCIだけではバグを見逃す
    7.6　2つのグラフの物語：デフォルトを7日間へ
    7.7　2つのグラフの物語：デフォルトを30日間へ
    7.8　競合は検出されない場合もある
    7.9　単体テストはどうする？
    7.10　PRによるトリガーではバグがまだ紛れ込む
    7.11　マージ前「と」マージ後のCI（3つの選択肢）
    7.12　選択肢1：CIを定期的に実行する
    7.13　選択肢1：定期的なCIの設定
    7.14　選択肢2：ブランチが最新であることを要求する
    7.15　選択肢2：その代償は？
    7.16　選択肢3：自動マージCI
    7.17　選択肢3：最新のmainブランチでのCI実行
    7.18　選択肢3：マージイベント
    7.19　選択肢3：マージキュー
    7.20　選択肢3：CoinExCompareのマージキュー
    7.21　あとはどこでバグが起きる？
    7.22　フレーキーテストとPRにトリガーされたCI
    7.23　定期的なテストでフレークを発見する
    7.24　バグとビルド
    7.25　CI vs ビルド＆デプロイ
    7.26　同じロジックでビルドとデプロイを行う
    7.27　ビルドが改善されたCIパイプライン
    7.28　変更の時系列を再確認する
    7.29　総括
    7.30　まとめ

第3部　デリバリーの簡略化

8章　簡単なデリバリーはバージョン管理から始まる
    8.1　Watch Me Watchでは……
    8.2　DORAメトリクス
    8.3　Watch Me Watchのベロシティ
    8.4　変更のリードタイム
    8.5　Watch Me Watchとエリートパフォーマー
    8.6　Watch Me Watchのベロシティ向上に向けて
    8.7　AllCatsAllTheTimeを統合する
    8.8　インクリメンタル（増分追加的）な機能のデリバリー
    8.9　スキップしたテストのコミット
    8.10　コードレビューと「未完成」なコード
    8.11　勢いを維持する
    8.12　作業途中のコードをコミットする
    8.13　作業途中のコードを見直す
    8.14　そうしている間に、エンドツーエンドのテストは……
    8.15　価値を確認する
    8.16　変更のリードタイムの短縮
    8.17　AllCatsAllTheTimeへの対応を続ける
    8.18　デプロイウィンドウとコードの凍結
    8.19　速度の改善
    8.20　総括
    8.21　まとめ

9章　安全かつ信頼性のあるビルド
    9.1　Top Dog Maps
    9.2　ビルドプロセスがドキュメントとして定義されている場合
    9.3　安全で信頼性の高いビルドの特徴
    9.4　常にリリース可能
    9.5　自動ビルド
    9.6　コードとしてビルドする
    9.7　CDサービスを利用する
    9.8　一時的なビルド環境
    9.9　ミゲルの計画
    9.10　ドキュメントからバージョン管理されたスクリプトへの移行
    9.11　コンテナのビルドを自動化
    9.12　安全で信頼性の高いビルドプロセスの完成
    9.13　インターフェースの変更とバグ
    9.14　ビルドがバグを引き起こすとき
    9.15　ビルドとコミュニケーション
    9.16　セマンティックバージョニング
    9.17　バージョン管理の重要性
    9.18　別の障害の発生！
    9.19　ビルド時の依存関係のバグ
    9.20　依存関係の固定
    9.21　バージョンの固定自体は保証ではない
    9.22　ハッシュも含めた依存関係の固定
    9.23　総括
    9.24　まとめ

10章　自信を持ってデプロイを行う
    10.1　デプロイに関する多くの問題
    10.2　安定性のためのDORAメトリクス
    10.3　Plenty of WoofsでのDORAメトリクス
    10.4　デプロイの頻度を低くすると……？
    10.5　デプロイの頻度を高くすると……？
    10.6　日次デプロイ vs サービス障害
    10.7　デプロイ頻度を上げるためのステップ
    10.8　デプロイプロセスの問題を修正する
    10.9　ローリングアップデート
    10.10　ローリングアップデートによるバグの修正
    10.11　ロールバック
    10.12　ロールバック戦略 = 即時改善
    10.13　ロールバックポリシーの実行
    10.14　ブルーグリーンデプロイメント
    10.15　ブルーグリーンで復旧時間を短縮する
    10.16　カナリアを使用してより高速かつ安定に
    10.17　カナリアデプロイメントの要件
    10.18　ベースラインを使用したカナリアデプロイメント
    10.19　カナリアデプロイメントの復元にかかる時間
    10.20　デプロイの頻度を増やす
    10.21　日次のカナリアデプロイメントによるDORAメトリクス
    10.22　継続的デプロイメント
    10.23　継続的デプロイメントを使用するにあたって
    10.24　必須のQAフェーズ
    10.25　QAと継続的デプロイメント
    10.26　DORAのエリートパフォーマンスを達成
    10.27　総括
    10.28　まとめ

第4部　継続的デリバリーのデザイン

11章　継続的デリバリーを始める
    11.1　始めるにあたって：この章の概要
    11.2　＜振り返り＞一般的なCDパイプラインのタスク
    11.3　典型的なリリースパイプライン
    11.4　典型的なCIパイプライン
    11.5　トリガー付きの2つのパイプライン
    11.6　＜グリーンフィールド＞継続的デリバリーを始める
    11.7　Gulpy
    11.8　ゼロから継続的デリバリーへ
    11.9　最初の一歩：ビルドできるか？
    11.10　継続的デリバリーの仕組みを選択する
    11.11　最初の自動化を構築する
    11.12　ソースコードの品質：リンティング
    11.13　ソースコードの品質：単体テスト
    11.14　ソースコードの品質：カバレッジ
    11.15　継続的インテグレーションの先へ：パブリッシュ
    11.16　デプロイメント
    11.17　テストの範囲を拡大する
    11.18　結合テストとE2Eテストのタスク
    11.19　CIパイプラインを完成させる
    11.20　完成したGulpy 社のパイプライン
    11.21　＜レガシー＞継続的デリバリーへの道のり
    11.22　Rebellious Hamster
    11.23　最初のステップ：段階的な目標を設定して優先度を付ける
    11.24　まず課題に焦点を当てる
    11.25　Rebellious Hamsterが抱える苦痛
    11.26　壊れていることを検知する
    11.27　テストの切り分けと追加
    11.28　レガシーパイプラインにテストを追加する
    11.29　デプロイをより自動化していく
    11.30　リリースパイプラインを作成する
    11.31　Rebellious Hamster 社のパイプライン
    11.32　完成したRebellious Hamster 社のパイプライン
    11.33　総括
    11.34　まとめ

12章　スクリプトはコードでもある
    12.1　Purrfect Bank
    12.2　継続的デリバリーの問題
    12.3　Purrfect Bank社の継続的デリバリーの概要
    12.4　ペイメント組織のbashライブラリ
    12.5　決済サービスのパイプライン
    12.6　巨大なスクリプトからの脱却
    12.7　うまく設計されたタスクの原則
    12.8　巨大なタスクを分解する
    12.9　決済サービスのパイプラインを更新する
    12.10　bashライブラリをデバッグする
    12.11　bashライブラリのバグを調査する
    12.12　なぜバグが起きたのだろうか？
    12.13　bashは何のためにある？
    12.14　bashが良くないのはどういうときか？
    12.15　シェルスクリプトと汎用言語の比較
    12.16　シェルスクリプトから汎用言語へ
    12.17　マイグレーション計画
    12.18　bashライブラリからbashのタスクへ
    12.19　タスクの中で再利用可能なbash
    12.20　bashからPythonへ
    12.21　コードとしてのタスク
    12.22　CDスクリプトもコードである
    12.23　総括
    12.24　まとめ

13章　パイプラインのデザイン
    13.1　PetMatch
    13.2　マッチメイキングのCDパイプライン
    13.3　CDパイプラインの問題
    13.4　E2Eテストパイプライン
    13.5　E2Eテストパイプラインとエラー
    13.6　Finallyの挙動
    13.7　Finallyタスクをグラフにすると
    13.8　マッチメイキングパイプラインのFinallyタスク
    13.9　E2Eテストパイプラインとスピード
    13.10　タスクの並列実行
    13.11　E2Eテストパイプラインとテストの速さ
    13.12　並列処理とテストのシャーディング
    13.13　E2Eテストパイプラインのシャーディング
    13.14　E2Eテストパイプラインとシグナル
    13.15　1つのCIパイプライン
    13.16　リリースパイプラインとシグナル
    13.17　継続的インテグレーションの違い
    13.18　パイプラインを組み合わせる
    13.19　リリースパイプライン
    13.20　ハードコーディングされたリリースパイプライン
    13.21　パラメーター化によるパイプラインの再利用
    13.22　再利用可能なパイプラインを使用する
    13.23　できあがったパイプライン
    13.24　PetMatch社の継続的デリバリー：解決された問題点
    13.25　注目すべき継続的デリバリーの機能
    13.26　総括
    13.27　まとめ

付録A　CDシステム
    A.1　章ごとに紹介したCDシステムの機能
    A.2　機能一覧
    A.3　Argo Workflows
    A.4　CircleCI
    A.5　GitHub Actions
    A.6　Google Cloud Build
    A.7　Jenkins Pipeline
    A.8　Tekton

付録B　バージョン管理システム
    B.1　バージョン管理システム：集中型と分散型
    B.2　バージョン管理のホスティング
    B.3　機能一覧
    B.4　Bitbucket
    B.5　GitHub
    B.6　GitLab

訳者あとがき
索　引