継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

著者 : David Farley Jez Humble 和智右桂 高木正弘

• KADOKAWA/アスキー・メディアワークス (2012年3月14日発売)

感想・レビュー・書評

[monmonさんの感想 · 2013年6月18日]

ゆっくり読み過ぎた。今ならバババっと読んじゃう感じだけど丁寧に読み過ぎてしまってた。
何度も同じ話出てくるし、ひと通り一気に読んでから気になるところ読み直す方が入ってきやすいと思う。
いい本だった。

[peccuさんの感想 · 2019年9月3日]

流し読み。
考慮できる場所がたくさん。最後の15章だけでも有用。

[ichiro.marinersさんの感想 · 2018年10月23日]

ソフトウエア開発チームが大切にすべき価値基準のうち、もっとも重要なことの一つが、「1行変更したソフトを安全にリリースできるまでのTAT（turn around time）が小さいこと」というのがこの本の趣旨。そのためのプラクティスがてんこ盛りだが、要は自動化できるものは自動化せよが、この本のメッセージだと思う。その通りなのだが、これがなかなか伝わらない。

[snow222さんの感想 · 2018年3月24日]

[図書館]
読了：2018/3/16

某資格試験のため。The DevOps Handbookより、こちらの方が理路整然と簡潔にまとまっていて読みやすかった。翻訳ものの常でやや冗長ではあるのだが。

継続的デリバリ、継続的デプロイメントの基本概念がそもそも分かっていなかった自分にちょうど良かった。

[chrojuさんの感想 · 2016年8月16日]

かなり記述が多い。また実際に用いる技術やツールの話ではなく、CDがなぜ必要なのか、いかなる考え方のもとで運用していくかということをつらつらと書き連ねた本。CD、CIを取り入れようとする際の精神的支柱になる感じがする。迷ったときはここに戻ってきたい、という本。

[enomotoさんの感想 · 2016年8月13日]

紹介されている構成管理やVCSのツール類に関しては今となっては古さが否めないが、CI / CD をなぜやるのかという思想、原則、プラクティスは現在にも有用であると感じた。DevOpsというバズワードが流行る前にその内容を詳解した良書。

[yusabanaさんの感想 · 2016年6月6日]

ボリュームは多かったけど内容はインフラの運用からアプリケーションの運用まで幅広かった。継続的にデリバリーする環境は楽しそうだなと思った。サービスを運用して改善などを常に続けていくということか。。

[miyohideさんの感想 · 2015年9月26日]

本のタイトルは「継続的デリバリー」だが継続的インテグレーションも話題に含んでいる。いわゆるCI/CDという部分での知見が詰まっている一冊と思う。

ツールを入れたら終わりという世界ではなく、如何にして「継続」するかがポイント。そのことについて多くのページを割かれていたように思う。

テストについては、書きすぎて疲労してしまうのが周りに多いんだけど、本書ではそれを早々に戒めている。自動テストでやるか、手動テストでやるか。その判断基準については明確には書かれておらず、プロジェクトごとごとに、それぞれの判断基準があるんだろうなと思う。

本書のベースとして「自動化することは良いこと」という大前提があって話が進んでいるので、例えば「これまで手でやっていてなんの問題もない。自動化することで何％効率化するの？根拠は？」っていう人たちを相手にすることになると本書は何も手助けにならない。そういう人たちを相手にするときは...どうしたらいいんでしょうねぇ。無視かなぁ。

閑話休題

全体的によく書かれています。似たような話が2度3度と書かれていてくどいと感じることはありますが、プロジェクトを進めるにあたって一通りのことは書かれているので、幸か不幸か「お前を自動テスト責任者とする」と言われた人は一度目を通しておくと良いかと思います。

[moke039さんの感想 · 2014年11月21日]

読み応えがあり、凶器にもなりそうな分厚い本を鈍器本と言うらしい。


ブランチ　先送り　エンジニアリング　小さくコミット　意味のあるまとまり


パラダイムシフト
ビッグバンテスト、ブランチを切る。いずれマージすることになる。
機能追加やリファクタリングのために作成したブランチはいずれ統合することになる。

マージのコンフリクトを解決するのは簡単な作業ではない。

生産性を図るのは難しい。タイムラグもある。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CannotMeasureProductivity

78 ツール
79

182 デリバリーの自動化　テストの自動化　の順
　　自動で短時間で苦労せず改善できないと使わなくなる
　　　　インクリメンタルなパイプライン改善　トヨタ生産方式に
　　　　通ず
ホーソン効果　制約理論（ボトルネック、集中、合わせる最適化する、別のボトルネックを探す）

リリース職人のあるべき姿

バージョン情報を起動Logに埋め込む　バナー　自動化
perl python ruby

232　DI car engine コンストラクタで車にエンジンを与える

フィクスチャ
受け入れテスト　実行可能な仕様　顧客も合意する　いっしょに作る
ふできることを理解する。

262 テストしやすい設計としてのバックドアは必要悪か、ただの悪か。

268　収穫逓減の法則

285 クヌース先生 パフォーマンス、スループット、キャパシティ。
　　　後回し、楽観視しすぎ、不安視しすぎ。

287 あたり マルチスレッドプログラムの処理時間。スライスしないほうが早い。
他にも高トラフィック時のキャッシュ対策は正しいが通常トラフィック時に遅くなる
システムの話などが興味深い。

324　緊急時はロールバックか、通常通りの手順でリリースする
325　

我々のパラダイム・シフト。コミット後、失敗するのは当然。

P423
経験がものを言うところだ。

コンポーネントをまとめる。コンポーネントにすべて分割する。

ある程度まとまらないとモジュールにならない。ドキュメントも同じ。ソースコードも
同じ。
goto 文を使うな。マジックナンバを使うな。デザインパターンに近づく、離れる。



P485
エンタープライズガバナンス
コーポレートガバナンス 適合性　運用
ビジネスガバナンス パフォーマンス 開発

P486 下
リリースしていないソフトは不良在庫

489
ITIL デベロップメント・デプロイ軽視
　　要求工学、マネジメント、XDDP

491
開始期の計画、戦略、おおまかな決定
494
真のイテレーティブと進捗の見える化
495
開発手法は大事　でも未熟な開発者がぐちゃぐちゃにしたコードは、
開発手法だけで自動的にきれいにはならない。
scrum が技術的側面を軽視しているように誤解する人がいる。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?FlaccidScrum

P308のリリース戦略も参照のこと。

506
ドキュメントを詳細に作りこめば作りこむほど、その内容が現実と食い違ってしまうのも早くなる。

デミング　PDCAサイクル

[daipresentsさんの感想 · 2014年10月30日]

受け入れテストの自動化のところが参考になった

著者プロフィール

継続的デリバリーの先駆者（『継続的デリバリー』の共著者）であり、継続的デリバリー、DevOps、TDD、その他ソフトウェア開発全般についてのソートリーダー、エキスパートプラクティショナー。コンピューティングの初期の時代から長年に渡ってプログラマー、ソフトウェアエンジニア、システムアーキテクト、成功したチームのリーダーとして活躍、コンピューターとソフトウェアが機能する仕組みについての基本原理を理解した上でソフトウェア開発に対する従来のアプローチをひっくり返すイノベーティブで画期的なアプローチを生み出してきた。

「2022年 『継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣』 で使われていた紹介文から引用しています。」