PR：この記事にはアフィリエイトリンクが含まれます。
継続的デリバリーの本には、考え方を学ぶものや特定のCIサービスを動かすものがあります。本番の信頼性や組織づくりまで扱う本も。いま悩んでいる工程に近い一冊なら、読んだ内容をチームのパイプラインに生かしやすいですよ。
ここでは、変更を検証してリリース可能な状態へ運ぶ仕組みと、本番へ安全に届ける仕組みを紹介します。自動化の設定に加えて、リリース判断の基準も学べる4冊です。
継続的デリバリーとは、変更を小さく保って必要な検証を通し、いつでもリリースできる状態を整える考え方です。デプロイを自動化しても、利用者への公開まで自動にするとは限りません。この違いを押さえられる本を集めました。
本の早見表
まずは4冊の特徴を一覧にまとめました。全体像からCircleCIの実装、本番の信頼性や組織の改善まで、扱うテーマはさまざま。同じCIとCDの本でも、読後に得られる知識はかなり違います。
| 本 | 中心テーマ | 参考価格（税込） |
|---|---|---|
 入門 継続的デリバリー | パイプラインの設計と自動化 | 4,180円 |
 CircleCI実践入門 ──CI/CDがもたらす開発速度と品質の両立 | CircleCIでのビルド・テスト・デプロイ | 3,278円 |
 サイトリライアビリティワークブック ―SREの実践方法 | SLOと段階的リリース | 5,060円 |
 LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する | 組織の測定と継続的改善 | 3,080円 |
価格は公式の希望小売価格を参考にしています。実売価格は時期や販売店で変わるため、購入時に確認を。いずれも紙版で、ページ数は320〜516頁です。しっかり読み込める技術書ですね。
CIやCDの設定に取り組みたい人と、組織の開発速度を見直したい人では、手に取る本も変わります。各書の得意分野と、実務へのつながりを順に見ていきましょう。
全体像を学ぶ
『入門 継続的デリバリー』は、これから導入するエンジニアにおすすめです。2024年刊の420頁、B5変判。変更を検証し、リリースへつなぐ工程を基礎からたどれます。4冊の中で刊行年が最も新しい本です。
パイプラインをコマンドの連結以上の仕組みとして扱う点が特徴です。タスク、ゲート、トランスフォーメーションを分けて考えると、何を変換し、どこを合格条件にするかが設計課題として見えてきます。
各章に実践シナリオがあり、付録ではArgo Workflows、CircleCI、GitHub Actions、Google Cloud Build、Jenkins Pipeline、Tektonを扱います。共通の考え方から身につけたい人に、最初の一冊として勧めます。
CircleCIで実装
CircleCIで継続的インテグレーションとデリバリーを組みたいWeb開発者には、『CircleCI実践入門』がおすすめです。416ページのA5判で、設定例やTipsを交えながら、ビルド、テスト、デプロイの実践を追えます。既存設定を読み解く手がかりにもなるでしょう。
ジョブの並列実行、キャッシュ、テスト結果の表示を通じて、待ち時間の短縮と検証結果の把握を扱います。失敗を早めに見つけ、次の変更へ戻れる流れを考えられるのが実務的です。
承認ジョブやフィーチャーフラグ、ECR・ECSへのデプロイ例を紹介。本番環境でのテストに加え、ロールバックやカナリア、ブルーグリーンデプロイ、ローリングデプロイも扱います。2020年刊なので、画面や設定構文を試す際はCircleCIの現行資料も確認しましょう。
SREで守る本番
開発と運用の両方に携わる人には、『サイトリライアビリティワークブック』をおすすめします。2020年刊の516頁、B5変判で読み応えがあります。Googleの知見に加え、Evernote、The Home Depot、New York Timesの事例も収録。
リリース可否をテスト結果だけで決めないことが、この本の大切な視点です。SLOとエラーバジェットを手がかりに、サービスの信頼性を踏まえて変更リスクを判断します。速度を上げるほど、利用者への影響を測る基準が欠かせませんよね。
カナリアリリースでは、対象数や実施期間、確認する指標をどう設定するかが焦点です。段階的に展開する判断や、ブルーグリーン方式の使い方まで考えたいチームに勧めます。
組織で改善する
『LeanとDevOpsの科学［Accelerate］』は2018年刊、320ページのA5判です。数年にわたる調査研究を基に、開発組織のパフォーマンスや組織文化を測り、改善する仕組みを解説します。CIツールの操作本とはテーマが異なります。
デプロイやテストをしやすくするアーキテクチャと、継続的デリバリーの原則や効果を取り上げています。リリース頻度だけを目標にすると、変更の失敗や復旧にかかる時間が見えず、成果を判断しにくくなります。
軽量な変更管理や、チームで実験を続けるプラクティスも紹介。個人の作業を急がせず、待ち時間や引き継ぎを減らす組織をつくりたい人に適しています。複数チームで共通の改善指標を持つ際にも参考になります。
変更が届く経路
実務のパイプラインでは、コードの変更から本番での判断までをひと続きにします。小さなWebサービスなら、検証とリリースを次のように段階化できます。最初からすべてを自動にしなくても大丈夫です。
- コミット時はフォーマットや静的解析、単体テストを実行して、明らかな不備を早く検出します。
- ビルド時は検証済みの成果物を一度作り、テスト環境と本番環境で共通して使います。
- ステージング時には連携テストと設定値を確認し、本番へ進める条件をチームで共有します。
- リリース時は少数の利用者へ公開し、エラー率などを見てから対象を広げます。
環境ごとに成果物を作り直すと、テストしたものと公開したものが異なる状態になりかねません。同じ成果物を次の環境へ進めれば、差分の原因を追いやすくなります。承認を挟む場合は、確認する内容を明確にしましょう。
デプロイはプログラムを環境へ配置する工程で、リリースは機能を利用者が使える状態にすることです。この二つを分けると設計を整理できます。フィーチャーフラグを使えば、配置と公開のタイミングをずらせる場合もあります。
自動化の信頼性
パイプラインが緑でも、安全が保証されるわけではありません。テストが不安定で失敗の理由を毎回調べる状態では、開発者が警告を無視し始めるおそれがあります。失敗の再現性と、修正後にすばやく再実行できることも品質の一部です。
認証情報をリポジトリに直接書かず、実行環境の権限は必要な範囲に絞ります。本番用の強い権限を、すべてのテストジョブへ渡す必要はありません。ジョブを分けると、漏えいや誤操作の影響も抑えやすくなります。
リリース後の監視や停止条件も、パイプライン設計の一部です。エラー率や応答時間が悪化したら段階展開を止め、戻す手順も事前に試しておきます。異常の検知と被害の抑制を考慮しながら、自動化の範囲を広げましょう。
結論
最初の一冊には『入門 継続的デリバリー』をおすすめします。特定ツールの設定に入る前に、パイプラインの設計を学べます。複数の実装例にも考え方をつなげられるため、初学者が全体像をつかむ目的に合っています。
CircleCIを使い、設定やデプロイを改善したい人には『CircleCI実践入門』。SLOを軸に本番リリースを判断したいチームには『サイトリライアビリティワークブック』、複数チームの仕組みを変える人には『LeanとDevOpsの科学』をおすすめします。
読んだ内容を現場へつなげるには、自チームのパイプラインに当てはめるのが近道です。待ち時間やリリースの失敗、復旧にかかる時間から改善対象を一つ決めて読み始めると、購入後の行動につながります。
Amazon の PC をスコア化してみた
Amazonにある8〜14インチの小型WindowsタブレットやノートPCを、スペック別にスコア化して比較・ランキング。
