継続的デリバリー の商品レビュー

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

2018/10/23

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

2018/03/24

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

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

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

2016/08/16

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

2016/06/06

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

2015/09/26

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

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

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

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

閑話休題

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

2015/10/03

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

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

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

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

生産性を図るのは難しい。タイムラグもある。
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サイクル

2014/09/04

後のマージが大変になるから、あまりブランチは切らないっていう話が少し意外だった。
あと、うちのプロジェクトのことを考えると、継続的デリバリーをやるには、テストに時間がかかり過ぎるのがネックだなと。デイリービルド＆テストから、コミットトリガーへの移行は、やるとしてもかなり時間がかかりそう。
前半はそこそこ集中して読めたのだけど、後半はだれてしまった。

2013/12/27

ユニットテストやビルドの自動化から始まって、デプロイや統合テスト、最終的には受け入れテストまで自動化するにはどうしたらいいか。
なかなかコストを費やさないと厳しいと思われる項目も多いが、長い目で見ると確立しておいたほうがいいんだろうなと。

「任意のポイントに戻せる」ことは大事。GUIまわりのテストの自動化は難しい。

2013/07/31

「リリース」に身構えない。こわくない。主題の deployment pipeline はパッケージソフトでもWebサービスでも開発すること全てに当てはまる話。作業をステージに区切ることで段階的な自動化もやりやすく、テストのスコープも明確にできる。しかし内容は抽象的な言い回しも多く難しくて、経験が無いとわからないこともたくさん。読んでは積んで、を繰り返して結局半年以上かかったが、十分に価値があった

2013/06/18

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