ギフトで購入

継続的デリバリー

Jez Humble, David Farley(著), 和智右桂, 髙木正弘(訳)

3,344円 (3,040円+税)

現代では継続的にソフトウェアをリリースすることが必須になっています。本書は、継続的なソフトウェアのデリバリーを実現するためのビルド、デプロイ、テスト、リリースの自動化についての本格的な解説書です。

内容紹介

本書では、アイデアが実際のビジネス的価値になるまでの時間――つまりサイクルタイム――を短く安全にすることによって、ソフトウェアのデリバリーに革命を起こす方法を説明する。
ソフトウェアというものは、ユーザーの手に渡るまでは何も価値を生み出さない。これはわかりきったことだが、ほとんどの組織ではソフトウェアを本番環境にリリースするプロセスは、手作業で行われて集中力を要し、エラーの起こりやすい、リスクのあるものなのだ。一般にはサイクルタイムが数ヶ月単位だと言ったが、もっと時間のかかる企業も多い。リリースサイクルが1 年以上だという企業すら、ないわけではないのだ。巨大な企業にとっては、アイデアが生まれてからそれを実装したコードをリリースするまで1 週間遅れるごとに数百万ドルのチャンスロスが発生しているかもしれないのだ。しかも、サイクルタイムが長すぎることに伴う問題はこれだけではない。
それにもかかわらず、ソフトウェアのデリバリーに伴うリスクを下げる仕組みやプロセスは、今日のソフトウェア開発プロジェクトのほとんどにとって未だ当たり前のことにはなっていない。
我々の目的は、開発者の手から本番へソフトウェアをデリバリーするプロセスを、信頼でき、あらかじめ何が起こるかわかり、可視化され、大部分が自動化されたものにすることにある。それによってリスクも適切に理解されて定量化可能になる。本書で記述したアプローチを用いれば、あるアイデアを思いついてからそれを実装した動くコードを本番にデリバリーするまで、ものの数分から数時間でできるようになり、同時にデリバリーされるソフトウェアの品質も改善できるようになる。
うまく動くソフトウェアをデリバリーすることに伴うコストの大半は、最初のリリースの後に発生する。それはサポートや保守、新しいフィーチャの追加、障害の修正などにかかるコストだ。ソフトウェアがイテレーティブなプロセスによってデリバリーされる場合には特にそうだ。その場合、最初のリリースでは顧客に価値をもたらす機能は最低限しか含まれていない。かくして、本書のタイトルである「継続的デリバリー」は、アジャイルマニフェストの最初の条文からとられている。「我々が最も価値を置くのは、価値あるソフトウェアを早いうちから継続的にデリバリーすることを通じて顧客を満足させることである」。この条文は現実を反映している。ソフトウェアを成功させることを思えば、最初にリリースすることはデリバリープロセスを成功させる上で始まりにしかすぎない。
本書で記述しているテクニックはどれも、ソフトウェアの新しいバージョンをユーザーにデリバリーする際の時間やリスクを低くするものだ。そのためにフィードバックを増やし、デリバリーにかかわる開発者やテスター、運用担当者間の共同作業を改善するのである。こうしたテクニックを用いることによって、バグフィックスであれ、新しいフィーチャの追加であれ、アプリケーションを修正する必要があるときに、アプリケーションを修正してからその結果を使えるようにデプロイするまでの時間をできる限り短く保てるようになる。問題はまだ容易に修正できる早期に発見され、関連するリスクも適切に理解される。
（「序文」より）

※本書は、株式会社KADOKAWA/アスキー・メディアワークスより刊行された『継続的デリバリー』を再刊行したものです。再刊行にあたり、旧版刊行後に発見された誤植等を修正しております。

書誌情報

著者: Jez Humble, David Farley(著), 和智右桂, 髙木正弘(訳)
発行日: 2017-07-31 (紙書籍版発行日: 2017-07-31)
最終更新日: 2017-07-31
バージョン: 1.0.0
ページ数: 545ページ(PDF版換算)
対応フォーマット: PDF, EPUB
出版社: アスキードワンゴ

対象読者

著者について

Jez Humble

11才でZX Spectrumに出会って以来、ジェズ・ハンブルはコンピュータと電子工学に魅せられている。その後、エイコーン・コンピュータやARMアセンブラ、BASICなどを経て大人になり、仕事に就く。ジェズがITの世界に入ったのは2000年のことだった。ちょうどドットコム・クラッシュが起きたときである。そのとき以来、彼は幅広く仕事をしている。開発者、システム管理者、トレイナー、コンサルタント、マネージャー、そしてスピーカー。ジェズはさまざまなプラットフォームや技術を扱い、非営利団体やテレコム、金融サービス、オンラインレンタル企業などのコンサルを行っている。2004年以来、ジェズはThoughtWorksと、北京、バンガロール、ロンドン、サンフランシスコのThoughtWorks Studioで働いている。オクスフォード大学の物理学および哲学の学士と、ロンドン大学東洋アフリカ学部民族音楽学の修士を有している。現在は、サンフランシスコに妻と娘と住んでいる。

David Farley

デイブ・ファーレイがコンピュータを好きになってから、30年近くが経つ。その経験の中で、デイブはほとんどの種類のソフトウェアを作ってきた。ファームウェアから、OSとデバイスドライバの整備を経て、ゲームや商用アプリケーションまで。しかも、あらゆる種類や規模のものを手がけてきたのだ。大規模な分散システムに初めて携わったのは20年以上前のことだ。疎結合でメッセージベースのシステムの開発の研究を行ったのだ。SOAの先駆けである。デイブは、複雑なソフトウェアを開発するチームリーダーを英国とアメリカで幅広く経験している。その中には、大規模なものもあれば、小規模なものもあある。デイブはアジャイル開発テクニックのアーリーアダプターであり、1990年代前半より商用プロジェクトで、イテレーティブな開発や継続的インテグレーション、かなりの量の自動テストなどを採用してきた。デイブのアジャイル開発に対するアプローチは、ThoughtWorksに勤めた四年半で磨き上げられた。ThoughtWorksの中でも最大で最も挑戦的なプロジェクトのいくつかで、技術的なリーダーを務めたのだ。デイブは現在、London Multi-Asset Exchange（LMAX）に勤務している。この組織は、世界でも最も高性能な金融為替システムを構築している。そこでは、本書で説明されている主なテクニックがすべて使われている。

和智右桂

オブジェクト指向を愛する思想系プログラマ。グロースエクスパートナーズ株式会社IT アーキテクト。本書のタイトルにもある「デリバリー」をキーワードに、要件定義、方式設計から開発、テストまでロールにとらわれずに仕事をしている。翻訳は趣味。海外のブログ記事などをときどき翻訳して公開している。訳書に『エリック・エヴァンスのドメイン駆動設計』（翔泳社、共訳）がある。認定プロダクトオーナー、認定スクラムマスター。
Blog: http://d.hatena.ne.jp/digitalsoul/
Twitter: @digitalsoul0124

髙木正弘

1972 年大阪府生まれ。仕事で使うことになったのがきっかけでオープンソースソフトウェアに興味を持ち、さまざまなプロジェクトでドキュメントの翻訳に携わるようになる。カメラ片手にあちこちに出歩くこと、そしておいしいお酒を飲むことが大好き。訳書に『プログラミングPHP 第2版』（オライリー・ジャパン）、『オープンソースソフトウェアの育て方』（共訳：オライリー・ジャパン）など。
Twitter: @takagi

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 実際にデプロイメントを行う人たちを、デプロイメントプロセスの策定に参加させよ329
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 まとめ

継続的デリバリー

関連サイト

内容紹介

書誌情報