投稿元:
レビューを見る
ソフトウェアを開発する上で非常に大切な考え方だと思います。ただ、後半のデータ管理のあたりから実際の作業との関連が想像し辛く理解が難しかった。
投稿元:
レビューを見る
ボリュームは多かったけど内容はインフラの運用からアプリケーションの運用まで幅広かった。継続的にデリバリーする環境は楽しそうだなと思った。サービスを運用して改善などを常に続けていくということか。。
投稿元:
レビューを見る
日本語で読めるのは非常にうれしい。
世の中の動きはすさまじく早く、今までのやり方では対応不可能。
様々なプラックティスを取り入れていかなければ生き残れない。
また、読むだけではなく、実践しなければなにも身につかない。
投稿元:
レビューを見る
最初から順番に読むよりは、しおりを2,3枚用意して、章の途中で別の章に飛んだり、気になるところからどんどん読んでいくのがいい感じ。
CIの前提となる自動化されたテストのためのデータの用意の仕方、考え方などが章の中で順序立てて体系的に示されていて助かった。
継続的インテグレーションに取り組みつつも悩んでいることに対するヒントや方向性がばんばん示されてほんとうに助かる。
投稿元:
レビューを見る
「リリース」に身構えない。こわくない。主題の deployment pipeline はパッケージソフトでもWebサービスでも開発すること全てに当てはまる話。作業をステージに区切ることで段階的な自動化もやりやすく、テストのスコープも明確にできる。しかし内容は抽象的な言い回しも多く難しくて、経験が無いとわからないこともたくさん。読んでは積んで、を繰り返して結局半年以上かかったが、十分に価値があった
投稿元:
レビューを見る
顧客に価値を届けるということは、
本番環境にソフトウェアをリリースし、
サービスが稼動しているということ。
つまり手前の状態では価値は無い。
価値を測る基準はリリースまでの期間となる。
もちろんミスやバグは許されない。
品質の高いものをリリースする必要がある。
品質を作りこみ、リリースまでの期間を短くするために、
ビルド・テスト・デプロイメントを自動化する。
当然最初の自動化するために痛みを伴うことになる。
自分たちはどこまでできているのだろうか?
皆さんの構成管理およびリリース管理の成熟度モデル(P.487)は、
レベルいくつですか?
(以下抜粋。○:完全抜粋、●:簡略抜粋)
○ケントが率いる統率されたチームには興味深い特徴がいくつもあったが、
そのひとつがソフトウェアを毎晩本番にデプロイしているという事実だった。(P.22)
●アンチパターン:ソフトウェアを手作業でデプロイする(P.41)
・広範囲にわたる詳細な手順書を作成し、リリースに必要なステップを記述する。
また考えられる間違いについても記述する。
・アプリケーションが正しく動作していることを確認するために、
手動テストに頼る。
・リリース当日にデプロイメントがうまくいかず、
その理由を開発チームに対して頻繁に問い合わせる。
○大きな組織では、デリバリープロセスは別々のグループに分類されている。
たとえば、データベース管理者、運用担当者、テスターなどだ。
こうしたサイロをまたいで協力しあうコストは膨大で、
申請書地獄のせいでリリースが遅くなってしまう。
このような場合、開発者やテスターそれに運用担当者はデプロイメントを行うときに、
常に申請書を提出しあうことになる(あるいはメールを送りあうことになる)。(P.45)
○ストレスを軽減するための鍵はこれまで説明してきた
ある種の自動デプロイメントプロセスを準備することだ。
そしてそのプロセスをこまめに実行し、
万が一最悪の事態が起きても変更前の状態に戻せる筋書きをと唱えておくのだ。
初めて自動化するときには、痛みを伴うことになる。
しかし、そのうち間単になっていき、
プロジェクトやあなた自身が受け取れる恩恵は計り知れないくらい大きくなるのだ。(P.58-59)
○テストが苦痛を伴うプロセスで、
リリースの直前に行われているのであれば、
最後になってやるのをやめよう。(P.64)
○非常に奇妙でありながら多くのソフトウェアプロジェクトに共通して見られる性質がひとつある。
それは、開発プロセスの長い間アプリケーションが動く状態にな、というものだ。(P.95)
○高品質を実現するために、大人数での調査に頼るのをやめよ。
まずはプロセスを改善し、本番の品質を作りこめ。(P.127)
●デプロイメントパイプラインを実装する���P.180
・コードがコンパイルできる
・コードは開発者の期待通りに動く。
なぜなら、ユニットテストを通っているから。
・システムはユーザの期待通りに動く。
なぜなら、受け入れテストを通っているから。
・コードには適切なコンポーネントがそろっている。
なぜなら、デプロイできるから。
↓ 実装する。
1.バリューストリームをモデル化して、動くスケルトンを作成する。
2.ビルドとデプロイプロセスを自動化する。
3.ユニットテストとコード解析を自動化する。
4.受け入れてストを自動化する。
5.リリースを自動化する。
○ソフトウェアデリバリープロセルにとって、
最も重要なグローバルメトリクスは、
リサイクルタイムである。(P.186)
○受け入れてストの自動化をあきらめたチームでは、
はるかに重い負荷がテスターにかかることになる。(P.244)
○自動テストを新しくはじめた人は、
コードをテストしやすくするためには設計アプローチを変える必要があることが気づく(P.262)
○細かい効率化については忘れることだ。
97%ぐらいの状況がそうだろう。
早まった最適化は諸悪の根源である。
しかし、重要な残り3%について見逃してはいけない。
良いプログラムはそんな論法では納得せず、
問題のコードを注意深く吟味するだろう。
しかし、それができるのは問題のコードが特定できてからである。(P.285)
○更新するかしないかを決めるために必要な情報が何も与えられないまま、
判断を迫られているようなものだ。(P.327)
○悲観的ロックシステムのゆーざはこんな心配をしているらしいという話を聞いた。
「楽観的ロックシステムのユーザは、
いつもマージ時の衝突の解消に時間を取られているのではないか」
あるいは「自動マージのせいで実行できないコード
やコンパイルの通らないコードができあるのではないか」
といった心配である。
実際のところ、そんな心配は杞憂ににすぎない。
マージ時の衝突は確かに発生する。
大規模なチームならかなりの頻度で発生するだろう。
しかし、通常はそのほとんどすべてが数秒からせいぜい数分で解決できるものだ。
もしそれ以上時間がかかることがあるとすれば、
それは先ほどの説明した指針に従わずに
コミットの頻度を十分上げなかったときぐらいだろう。(P.453)
投稿元:
レビューを見る
てっきりデプロイ自動化やCI回す効率的な方法論が書いてあるのかと思っていたけど期待とは違っていた。
デプロイ自動化やCI回すその先の仕事の価値観、プロジェクトメンバーとの共有等の人の事について書かれている。
まだまだデプロイ自動化やテスト開発をしていないので、その先の事を書かれても理解出来ない所があるが、きっとデプロイ自動化やテスト開発をした後の事に役立つのであろう。
分厚く、同じような事が何度も書かれているので気になった所をパラパラと読むのが良いだろう。
また、必要になった時に読み直したい。
投稿元:
レビューを見る
ゆっくり読み過ぎた。今ならバババっと読んじゃう感じだけど丁寧に読み過ぎてしまってた。
何度も同じ話出てくるし、ひと通り一気に読んでから気になるところ読み直す方が入ってきやすいと思う。
いい本だった。
投稿元:
レビューを見る
ユニットテストやビルドの自動化から始まって、デプロイや統合テスト、最終的には受け入れテストまで自動化するにはどうしたらいいか。
なかなかコストを費やさないと厳しいと思われる項目も多いが、長い目で見ると確立しておいたほうがいいんだろうなと。
「任意のポイントに戻せる」ことは大事。GUIまわりのテストの自動化は難しい。
投稿元:
レビューを見る
後のマージが大変になるから、あまりブランチは切らないっていう話が少し意外だった。
あと、うちのプロジェクトのことを考えると、継続的デリバリーをやるには、テストに時間がかかり過ぎるのがネックだなと。デイリービルド&テストから、コミットトリガーへの移行は、やるとしてもかなり時間がかかりそう。
前半はそこそこ集中して読めたのだけど、後半はだれてしまった。
投稿元:
レビューを見る
読み応えがあり、凶器にもなりそうな分厚い本を鈍器本と言うらしい。
ブランチ 先送り エンジニアリング 小さくコミット 意味のあるまとまり
パラダイムシフト
ビッグバンテスト、ブランチを切る。いずれマージすることになる。
機能追加やリファクタリングのために作成したブランチはいずれ統合することになる。
マージのコンフリクトを解決するのは簡単な作業ではない。
生産性を図るのは難しい。タイムラグもある。
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サイクル
投稿元:
レビューを見る
本のタイトルは「継続的デリバリー」だが継続的インテグレーションも話題に含んでいる。いわゆるCI/CDという部分での知見が詰まっている一冊と思う。
ツールを入れたら終わりという世界ではなく、如何にして「継続」するかがポイント。そのことについて多くのページを割かれていたように思う。
テストについては、書きすぎて疲労してしまうのが周りに多いんだけど、本書ではそれを早々に戒めている。自動テストでやるか、手動テストでやるか。その判断基準については明確には書かれておらず、プロジェクトごとごとに、それぞれの判断基準があるんだろうなと思う。
本書のベースとして「自動化することは良いこと」という大前提があって話が進んでいるので、例えば「これまで手でやっていてなんの問題もない。自動化することで何%効率化するの?根拠は?」っていう人たちを相手にすることになると本書は何も手助けにならない。そういう人たちを相手にするときは...どうしたらいいんでしょうねぇ。無視かなぁ。
閑話休題
全体的によく書かれています。似たような話が2度3度と書かれていてくどいと感じることはありますが、プロジェクトを進めるにあたって一通りのことは書かれているので、幸か不幸か「お前を自動テスト責任者とする」と言われた人は一度目を通しておくと良いかと思います。
投稿元:
レビューを見る
かなり記述が多い。また実際に用いる技術やツールの話ではなく、CDがなぜ必要なのか、いかなる考え方のもとで運用していくかということをつらつらと書き連ねた本。CD、CIを取り入れようとする際の精神的支柱になる感じがする。迷ったときはここに戻ってきたい、という本。
投稿元:
レビューを見る
[図書館]
読了:2018/3/16
某資格試験のため。The DevOps Handbookより、こちらの方が理路整然と簡潔にまとまっていて読みやすかった。翻訳ものの常でやや冗長ではあるのだが。
継続的デリバリ、継続的デプロイメントの基本概念がそもそも分かっていなかった自分にちょうど良かった。
投稿元:
レビューを見る
ソフトウエア開発チームが大切にすべき価値基準のうち、もっとも重要なことの一つが、「1行変更したソフトを安全にリリースできるまでのTAT(turn around time)が小さいこと」というのがこの本の趣旨。そのためのプラクティスがてんこ盛りだが、要は自動化できるものは自動化せよが、この本のメッセージだと思う。その通りなのだが、これがなかなか伝わらない。