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

制作 : 和智 右桂  高木 正弘 
  • KADOKAWA/アスキー・メディアワークス (2012年3月14日発売)
4.14
  • (12)
  • (18)
  • (5)
  • (1)
  • (0)
  • 本棚登録 :273
  • レビュー :20
  • Amazon.co.jp ・本 (544ページ)
  • / ISBN・EAN: 9784048707879

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

並び替え:

表示形式:

表示件数:

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

  • [図書館]
    読了:2018/3/16

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

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

  • Z6

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

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

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

  • 今の自分にはまだまだ遠いかなと感じました。
    理解云々ではなくて、むしろ共感は多いのですが、そこに至るまでの道のりが長く遠く感じてしまったので、もっともっと力をつけたいと思いました。

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

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

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

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

    閑話休題

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

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


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


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

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

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

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

全20件中 1 - 10件を表示

David Farleyの作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
エリック・リース
有効な右矢印 無効な右矢印

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

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化を本棚に登録しているひと

ツイートする