『継続的デリバリー』読書会
      第一章
ソフトウェアデリバリーの問題
   大崎的デリバリー
    @hidesuke
1.1 導入
           この本の目的
•  本書の焦点
 –  ビルド、デプロイ、テスト、リリースプロセ
    ス
 –  安全で信頼でき、素早くソフトウェアをリ
    リースできるようにする
•  ソフトウェアの開発からリリースまで効率
   的にすすめるためのパターンを解説する
1.1 導入
  デプロイメントパイプライン
•  ビルド・デプロイ・テスト・リリースと
   いったプロセスを自動化する実装
•  リリースする際の「価値の流れ(バリュー
   ストリーム)」は組織によって異なる
 –  組織毎に独自のデプロイメントパイプライン
    を実装
 –  どの組織でも原則は同じ
1.1導入
   デプロイメントパイプラインの例



          自動化された   自動化された
コミットステー                      手作業でのテ
          受け入れテス   キャパシティ             リリース	
   ジ	
                         スト	
             ト	
     テスト
1.1導入
  デプロイメントパイプライン
•  継続的インテグレーション(CI)のプロセ
   スが基礎となっている
 –  CIの考え方を論理的に突き詰めたもの
•  3つの目的
 –  見える化し共同作業をやりやすくする
 –  早い段階での問題特定/解決の手助け
 –  任意のバージョンのソフトウェアを任意の環
    境に完全に自動化されたプロセスを通して好
    きなようにデプロイできるようにする
1.2 リリースによくあるアンチパ
        ターン
•  リリース日 => 緊迫した空気
 –  プロセスが原因でリリースが恐ろしいものに
•  リリースのよくある風景
 –  手作業
 –  集中力が必要
 –  各ホストに手作業でソフトウェアをセット
    アップ
 –  構成要素を1つずつ手動でたちあげ
1.2 リリースによくあるアンチパ
        ターン
•  間違える可能性のある要素が多すぎる
•  一つでも間違えばアプリケーションは動か
   ない
1.2.1 アンチパターン:ソフト
 ウェアを手作業でデプロイする
•  広範囲にわたる詳細な手順書
 –  必要なステップが全て記述してある
 –  でも、リリース中に頻繁に修正
•  手動テストで動作確認
•  開発チームにデプロイがうまくいかない理由ついて頻
   繁に問い合わせ
•  クラスタ内に設定の異なるノードがある
•  数分単位でリリースが終わらない
•  リリースの結果が予測できない
 –  リリース前状態への切り戻し
 –  不測の問題に行き当たる
                                   	
•  帰れない
                            チパ ターン
                       アン
1.2.1 アンチパターン:ソフト
 ウェアを手作業でデプロイする
•  デプロイは完全に自動化するべき
•  人間がやるべきことは2つ
 –  どのバージョンをどの環境にデプロイするか
    を選択する
 –  デプロイボタンを押す




                     解 決策
1.2.1 アンチパターン:ソフト
 ウェアを手作業でデプロイする
•  自動化しないといけない
 –  手動だとエラーがおきる
 –  手動だと反復可能にならない、信頼できない。デ
    プロイで起こったエラーのバグに時間がとられる
 –  手順書を作らなくてよくなる
 –  デプロイスクリプトがあれば自動化できる
  •  デプロイをうまくやるためにデプロイスクリプトは常
     にメンテナンスされる
  •  共同作業が促進される
 –  デプロイメント職人が不要になる    解 決策
1.2.2 アンチパターン:開発が終わっ
 てから擬似本番環境にデプロイする
•  ステージングへのデプロイが必要になったと
   きに、初めてデプロイチームが招集される
 –  デプロイに必要なステップはステージング環境で
    テストされないことが多い
 –  ドキュメントが重要なステップを抜かしてる可能
    性
 –  ドキュメントやスクリプト上の想定が誤っていて、
    デプロイに失敗
 –  開発チームと協力していないので、失敗の原因を
    当て推量                  ン	
                        ンチ パター
                    ア
1.2.2 アンチパターン:開発が終わっ
 てから擬似本番環境にデプロイする
•  ステージングに最初にデプロイするときが最
   もトラブルが多い
•  リリースサイクルが長くなるほど、デプロイ
   の前に行う想定は不正確になり、修正に時間
   がかかる
•  大きな組織で、役割毎に組織が縦割りになっ
   ている場合、申請書提出地獄になる
•  開発環境と本番環境の違いが大きいほど、想
   定も現実と乖離する
 –  Windows機上でSolarisクラスタにデプロイする
    アプリを開発してるとか                     	
                             チパ ターン
                        アン
1.2.2 アンチパターン:開発が終わっ
 てから擬似本番環境にデプロイする
•  テスト・デプロイ・リリースを開発プロセ
   ス中に統合する
•  リリースを行うチーム、テスター、開発者
   まで全員がプロジェクトの最初から確実
   に協力しあう
•  ソフトウェアとデプロイプロセスの両方
   をテストする

                 解 決策
1.2.3 アンチパターン:本番環境につ
    いて手作業で構成管理を行う
例えばこんな場合	


•  本番環境の構成管理を運用担当チームで行
   なっている場合……
  –  本番サーバに対して手作業で変更が行われる
    •  データベース接続設定とか
  –  変更の記録が変更管理DBに残される
1.2.3 アンチパターン:本番環境につ
     いて手作業で構成管理を行う
•  ステージングへのデプロイは何度も成功して
   るけど、本番へのデプロイで失敗する
•  クラスタ内の別々のメンバで振る舞いが違う
     –  他のメンバだと耐えられる負荷に耐えられない子
        がいる
     –  処理に時間がかかる子がいる
•    運用チームがリリースのために時間がかかる
•    システムを以前の状態に戻せない
•    クラスタ内でバージョンが統一されていない
•    本番を直接編集で設定を修正
                                   	
                            チパ ターン
                       アン
1.2.3 アンチパターン:本番環境につ
    いて手作業で構成管理を行う
•  設定などは自動プロセスを通じてバージョン管理から
   適用されるべき
 –  テスト環境、ステージング環境、本番環境のあらゆる設定
 –  特にサードパーティーの要素の設定
•  構成管理にはあらゆる構成要素を繰り返し再現できる
   ということも含まれる
 –  OS、パッチレベル、OSの設置、アプリケーションスタッ
    クとその設定、基盤設定など、全てが管理されていなくて
    はならない
 –  仮想化はその第一歩
•  バージョン管理されていれば、以前のバージョンへの
   ロールバックも可能
                        解 決策
1.3 もっとうまくできないのだろ
        うか?
•  本書の目的→リリースをごく単純な作業に
   する
•  開発環境、テスト環境、本番環境までど
   んなデプロイ対象にもボタンひとつでソフ
   トウェアをリリースできるようにする
 –  小規模な開発チームだけでなく、分散した
    チームによる大規模なエンタープライズプロ
    ジェクトでも実施できる
1.4 どうすれば目標を達成できる
        か?
•  目標:役に立って動作するソフトウェアをで
   きる限り素早くユーザに届けること
•  サイクルタイムを減らす
 –  サイクルタイム:変更すると決めてからユーザが
    使えるようになるまでの時間
 –  機会損失を減らす/投資の回収を素早く開始する
•  サイクルタイムを最小化し、(顧客からの)効
   果的なフィードバックループを構築する
   => 素早いデリバリーが重要
1.4 どうすれば目標を達成できる
        か?
•  使い勝手おいて重要な部分を占めるのが品
   質
•  品質を適切なレベルに保つことが重要

•  高品質で価値のあるソフトウェアを効率
   的で素早く、信頼できるやり方でリリース
   する方法を見つけ出したい
1.4 どうすれば目標を達成できる
        か?
•  高品質で価値のあるソフトウェアを効率的で素早く、
   信頼できるやり方でリリースする方法を見つけ出した
   い


•  自動化
  –  ビルド・デプロイ・テスト・リリースを自動化し、こまめ
     に繰り返す
•  こまめに
  –  こまめなリリースによって、リリース間の差異を小さくす
     る
     => リリースリスクを小さく
  –  フィードバックを素早く得られるようにする
1.4 どうすれば目標を達成できる
        か?
•  フィードバック大事
 –  あらゆる変更はフィードバックプロセスを引
    き起こさなくてはならない
 –  フィードバックは早く伝えなくてはならない
 –  デリバリーチームはフィードバックを受け取
    り、それに対して行動を起こさなければなら
    ない

      ここで言っているフィードバックとは	
  
      変更に対してテストを実行した結果のことも指し
      ている	
  
1.4.1 あらゆる変更はフィードバックプロ
   セスを引き起こさなければならない
•  ソフトウェアアプリケーションの4つの要
   素
 –  実行可能なコード
 –  設定
 –  ホスト環境
 –  データ
•  どれかが変更されたら、そのせいでアプリ
   ケーションの振る舞いが変化する可能性が
   ある
1.4.1 あらゆる変更はフィードバックプロ
   セスを引き起こさなければならない
•  継続的インテグレーション(第3章で説明)
•  実行可能コード
 –  あらゆる環境にデプロイされるものと同一で
    なければならない
•  設定
 –  環境ごとに変更される必要があるものは設定
    情報として扱う必要がある
 –  設定変更されれば、どの環境であれテストし
    なければならない
1.4.1 あらゆる変更はフィードバックプロ
   セスを引き起こさなければならない
•  ホスト環境
 –  環境に変更があれば、環境を変更した上でシ
    ステム全体をテストしなければならない
 –  環境とはOS、ソフトウェア(ミドルウェア)、
    ネットワーク構成、あらゆる基盤や外部シス
    テムが含まれる
•  データ
 –  データ構造が変更されたらテストしなければ
    ならない(データ管理については12章)
1.4.1 あらゆる変更はフィードバックプロ
   セスを引き起こさなければならない
•  変更時のフィードバックプロセス
 –  前述した各種テスト
 –  受け入れテスト、非機能要件テスト
 –  顧客に対するデモンストレーション
•  できる限り完全に自動化されたテストの
   実施
   => フィードバックプロセスを引き起こす
1.4.2 フィードバックはできる限
り早く受けとらなければならない
•  素早いフィードバックの鍵は自動化
 –  プロセスが完全に自動化されていればハード
    ウェアを投入すればいくらでもスケールする
 –  繰り返し作業は機械に任せる
    => 人的リソースの用途を最適化する
1.4.3 デリバリーチームはフィードバックを受け
     取り、それに対応しなければならない

•  デリバリーチームがフィードバックプロセ
   スに関わっていることが重要
 –  頻繁に会うことで、デリバリープロセスの改
    善につながる
•  フィードバックに対応できる
   => 情報を広くつたえることに繋がる
•  フィードバックに対して、チーム全体の責
   任として対処する
1.4.4 このプロセスはスケールす
        るのか?
•  小さいチームでしかうまくいかない?
   => NO! 大小様々なプロジェクトで実践
   してきた方法について本書では解説してい
   る
•  リーン生産方式の影響をうけている
 –  リーンは巨大な組織のために作られたもの
 –  リーンの理論やプラクティスは小さいチーム
    と同様に大きなチームにも当てはまる
1.5 どんな恩恵を受けられるのか?

•  反復可能で信頼でき、予測可能なリリース
   プロセスの構築
 –  サイクルタイムの短縮
 –  コストの節約
•  その他にも恩恵がある
1.5.1 チームに権限を与える
•  プルシステム
 –  テスターや運用担当者、サポート担当者が自
    分の望むバージョンのアプリケーションを好
    きな環境に自分でリリースできるようにする
    こと
 –  従来はこういった人達は「適正なビルド」が
    提供されるのを待っていた
    => この待ちや手続きが非効率だった
1.5.1 チームに権限を与える
•  プルシステムによる恩恵の例
 –  テスターは古いバージョンのアプリを選択して、
    新しいバージョンにおける振る舞いの変更を検証
    できる
 –  サポート担当者はリリースされたバージョンのア
    プリをテスト環境にデプロイして、欠陥を再現さ
    せることができる
 –  運用担当者はディザスタリカバリーの演習の一貫
    として正しく動くとわかっているビルドを本番環
    境にデプロイできる
 –  リリースがボタンひとつで実行できる
1.5.1 チームに権限を与える
•  チームメンバーは自分たちの仕事をコント
   ロールできるようになる
•  仕事の品質が向上
•  アプリケーションの品質も向上
•  正しいビルドが渡されるのを待つ必要が
   なくなる
1.5.2 エラーを削減する
•  構成管理がまずいせいでエラーになる場合
   について述べる
•  (詳細は2章)
•  構成管理は、典型的なアプリケーションを
   動かすために適切に設定しなくてはなら
   ない
1.5.2 エラーを削減する
•  変化する可能性があるものをすべて、積極
   的にバージョン管理で管理する
 –  設定ファイル/DBスキーマ生成スクリプト/ビ
    ルドスクリプト/テストハーネス/デプロイメ
    ント環境/OSの設定
•  設定の適用をコンピュータを使うように
   する(人力で適用しない)
1.5.3 ストレスを低減する
•  リリースのストレスからの開放!

•  まずは自動のデプロイメントプロセスを準
   備しておく
•  リリースまでにこまめに実行
•  変更前の状態に戻せるようにもしておく
•  最初は痛みを伴うが、じょじょに簡単に
   なっていき、大きな恩恵が得られる
1.5.4 デプロイメントの柔軟性
•  新環境でアプリを動かしはじめるという
   タスクはシンプルであるべき
•  筐体や仮想イメージを作動させ、環境固有
   の設定情報をつくるだけにしたい
•  そこに自動化されたデプロイメントプロセ
   スを利用して環境構築&アプリのリリース
   を行う
1.5.5 「できるようになりたけれ
       ば、練習しろ」
•  どこにデプロイする場合でも、デプロイ
   のアプローチを同一にする
 –  特別な受け入れテストとか本番用のデプロイ
    戦略とかいうことがあってはいけない
 –  何回も本番にデプロイするのと同じ方法でデ
    プロイすることになる
•  唯一例外が許されるのは開発環境のみ
 –  開発者が自分でバイナリをビルドする必要が
    あったりするので
1.6 リリース候補
•  ビルドやデプロイの自動化が包括的な自動テ
   ストと併せて行われていれば、集中的で大々
   的な手動テストは必要ない
 –  手動テストは機能を満たしていることを確認する
    だけでよい
•  開発プロセス終了後にテストを実施すると品
   質は低下する
•  欠陥は素早く修正されるべき
 –  発見がおくれると修正にかかるコストは増加する
1.6.1 あらゆるチェックインは潜
   在的にリリースにつながる
•  統合フェーズでまとめて統合を行う
   => 統合フェーズまできちんと動いている
   かわからない! 痛みが大きすぎる!

•  こまめに統合する
 –  壊れたらすぐに修正
 –  ソフトウェアは常に動く状態が保たれる
 –  常にリリースできる状態
 –  継続的インテグレーションの第一のルール
1.7 ソフトウェアデリバリーの原則

•  ソフトウェアをリリースするための、反復可能で
   信頼できるプロセスを作り上げよ
•  ほとんどすべてを自動化せよ
•  すべてバージョン管理に入れよ
•  痛みを伴うものはこまめに実施し、痛い思いは早
   めにしておけ
•  品質を作り込め
•  完了したとはリリースしたということだ
•  誰もがデリバリープロセスに対して責任を負う
•  継続的改善
1.7.1 ソフトウェアをリリースするための、反復
    可能で信頼できるプロセスを作り上げよ

•  リリースが簡単 => 何回も(リリースする)
   テストができる
•  バージョン管理に端を発する完全に自動化
   されたプロセスを作ることが重要
1.7.2 ほとんどすべてを自動化せよ

•  自動化できないものは多くはない
 –  人間の指示や意思決定が必要になるプロセス
    直前までは自動化するべき
 –  受け入れテスト、DBのアップグレード/ダウ
    ングレード、ファイアウォールの設定も自動
    化できる
•  手作業のほうが簡単に思えるかもしれな
   いが、それを何回も繰り返すなら自動化
   したほうが楽
1.7.3 すべてバージョン管理にい
         れよ
•  バージョン管理できるストレージにありとあ
   らゆる物を保管しなくてはならない
 –  要件定義ドキュメント、テストスクリプト、自動
    テストのケース、ネットワーク構成スクリプト、
    デプロイメントスクリプト、初期化スクリプト、
    ツール群、ライブラリなどなどなど
•  変更セットは単一の識別子を保つ必要がある
•  新しいチームメンバーが新規の新しいマシン
   に座り、リポジトリからチェックアウトして、
   コマンドを1行実行したらアプリケーション
   がビルドできる必要がある
1.7.4 痛みを伴うものはこまめに実施
   し、痛い思いは早めにしておけ
•  最も役に立つ経験則
•  例) 統合はひどい苦痛を伴うプロセス
   => 誰かがチェックインするたびに統合を
   行おう! プロジェクトの最初から
•  とにかく苦痛と思うもの(リリース、結合、
   テスト、などなど)はこまめに普段から自
   動化して実施する
1.7.5 品質をつくりこめ
•  リーンからパクった原則
•  欠陥を早く見つけるほど、修正も安くあが
   る
•  継続的インテグレーションで、欠陥を常に
   検知できるようになった
   => すぐに修正できるようにする
•  チームが品質に対する責任を負う
1.7.6 完了したとはリリースした
       ということだ
•  「完了した」とは価値をユーザに届けたとき
 –  外部のユーザに価値が届くまでは時間がかか
    る……
•  擬似本番環境にリリースし、ユーザコミュニ
   ティの代表者(プロダクトオーナーや依頼者)
   に対してデモを行い、触ってもらったときが
   完了ということにしている
•  80%完了などない。完了したか、してないか
   のみ
1.7.7 誰もがデリバリープロセス
      に対して責任を負う
•  縦割りだと責任のなすりつけ合いになる
•  プロジェクトの最初から全員をデリバ
   リープロセスに巻き込む
1.7.8 継続的改善
•  アプリケーションは進化していく
   => デリバリープロセスも一緒に進化する
   ことは重要
•  デリバリープロセスに関する振り返りを行
   うべき
•  組織内の誰もがPDCAサイクルに関わる
 –  壁を設けない。縦割りしない。犯人探しにな
    らないようにする
1.8 まとめ
•  ビルド・テスト・デプロイメントを自動化
   する
 –  変更を確認できるようになる
 –  複数の環境にまたがってプロセスを再現でき
    るようになる
 –  本番にエラーが交じる可能性を大幅に低減で
    きる
 –  ビジネス上の利益を素早く提供できるように
    なる
 –  ワークライフバランスが改善される
感想
•    同じ事繰り返し何度もいってるので辛い
•    もっとまとめられそう
•    この本を元に違う本が書けそう
•    継続的デリバリー重要
•    宗教的
•    哲学的

継続的デリバリー読書会資料 #1

  • 1.
    『継続的デリバリー』読書会 第一章 ソフトウェアデリバリーの問題 大崎的デリバリー @hidesuke
  • 2.
    1.1 導入 この本の目的 •  本書の焦点 –  ビルド、デプロイ、テスト、リリースプロセ ス –  安全で信頼でき、素早くソフトウェアをリ リースできるようにする •  ソフトウェアの開発からリリースまで効率 的にすすめるためのパターンを解説する
  • 3.
    1.1 導入 デプロイメントパイプライン •  ビルド・デプロイ・テスト・リリースと いったプロセスを自動化する実装 •  リリースする際の「価値の流れ(バリュー ストリーム)」は組織によって異なる –  組織毎に独自のデプロイメントパイプライン を実装 –  どの組織でも原則は同じ
  • 4.
    1.1導入 デプロイメントパイプラインの例 自動化された 自動化された コミットステー 手作業でのテ 受け入れテス キャパシティ リリース ジ スト ト テスト
  • 5.
    1.1導入 デプロイメントパイプライン • 継続的インテグレーション(CI)のプロセ スが基礎となっている –  CIの考え方を論理的に突き詰めたもの •  3つの目的 –  見える化し共同作業をやりやすくする –  早い段階での問題特定/解決の手助け –  任意のバージョンのソフトウェアを任意の環 境に完全に自動化されたプロセスを通して好 きなようにデプロイできるようにする
  • 6.
    1.2 リリースによくあるアンチパ ターン •  リリース日 => 緊迫した空気 –  プロセスが原因でリリースが恐ろしいものに •  リリースのよくある風景 –  手作業 –  集中力が必要 –  各ホストに手作業でソフトウェアをセット アップ –  構成要素を1つずつ手動でたちあげ
  • 7.
    1.2 リリースによくあるアンチパ ターン •  間違える可能性のある要素が多すぎる •  一つでも間違えばアプリケーションは動か ない
  • 8.
    1.2.1 アンチパターン:ソフト ウェアを手作業でデプロイする • 広範囲にわたる詳細な手順書 –  必要なステップが全て記述してある –  でも、リリース中に頻繁に修正 •  手動テストで動作確認 •  開発チームにデプロイがうまくいかない理由ついて頻 繁に問い合わせ •  クラスタ内に設定の異なるノードがある •  数分単位でリリースが終わらない •  リリースの結果が予測できない –  リリース前状態への切り戻し –  不測の問題に行き当たる •  帰れない チパ ターン アン
  • 9.
    1.2.1 アンチパターン:ソフト ウェアを手作業でデプロイする • デプロイは完全に自動化するべき •  人間がやるべきことは2つ –  どのバージョンをどの環境にデプロイするか を選択する –  デプロイボタンを押す 解 決策
  • 10.
    1.2.1 アンチパターン:ソフト ウェアを手作業でデプロイする • 自動化しないといけない –  手動だとエラーがおきる –  手動だと反復可能にならない、信頼できない。デ プロイで起こったエラーのバグに時間がとられる –  手順書を作らなくてよくなる –  デプロイスクリプトがあれば自動化できる •  デプロイをうまくやるためにデプロイスクリプトは常 にメンテナンスされる •  共同作業が促進される –  デプロイメント職人が不要になる 解 決策
  • 11.
    1.2.2 アンチパターン:開発が終わっ てから擬似本番環境にデプロイする • ステージングへのデプロイが必要になったと きに、初めてデプロイチームが招集される –  デプロイに必要なステップはステージング環境で テストされないことが多い –  ドキュメントが重要なステップを抜かしてる可能 性 –  ドキュメントやスクリプト上の想定が誤っていて、 デプロイに失敗 –  開発チームと協力していないので、失敗の原因を 当て推量 ン ンチ パター ア
  • 12.
    1.2.2 アンチパターン:開発が終わっ てから擬似本番環境にデプロイする • ステージングに最初にデプロイするときが最 もトラブルが多い •  リリースサイクルが長くなるほど、デプロイ の前に行う想定は不正確になり、修正に時間 がかかる •  大きな組織で、役割毎に組織が縦割りになっ ている場合、申請書提出地獄になる •  開発環境と本番環境の違いが大きいほど、想 定も現実と乖離する –  Windows機上でSolarisクラスタにデプロイする アプリを開発してるとか チパ ターン アン
  • 13.
    1.2.2 アンチパターン:開発が終わっ てから擬似本番環境にデプロイする • テスト・デプロイ・リリースを開発プロセ ス中に統合する •  リリースを行うチーム、テスター、開発者 まで全員がプロジェクトの最初から確実 に協力しあう •  ソフトウェアとデプロイプロセスの両方 をテストする 解 決策
  • 14.
    1.2.3 アンチパターン:本番環境につ いて手作業で構成管理を行う 例えばこんな場合 •  本番環境の構成管理を運用担当チームで行 なっている場合…… –  本番サーバに対して手作業で変更が行われる •  データベース接続設定とか –  変更の記録が変更管理DBに残される
  • 15.
    1.2.3 アンチパターン:本番環境につ いて手作業で構成管理を行う •  ステージングへのデプロイは何度も成功して るけど、本番へのデプロイで失敗する •  クラスタ内の別々のメンバで振る舞いが違う –  他のメンバだと耐えられる負荷に耐えられない子 がいる –  処理に時間がかかる子がいる •  運用チームがリリースのために時間がかかる •  システムを以前の状態に戻せない •  クラスタ内でバージョンが統一されていない •  本番を直接編集で設定を修正 チパ ターン アン
  • 16.
    1.2.3 アンチパターン:本番環境につ いて手作業で構成管理を行う •  設定などは自動プロセスを通じてバージョン管理から 適用されるべき –  テスト環境、ステージング環境、本番環境のあらゆる設定 –  特にサードパーティーの要素の設定 •  構成管理にはあらゆる構成要素を繰り返し再現できる ということも含まれる –  OS、パッチレベル、OSの設置、アプリケーションスタッ クとその設定、基盤設定など、全てが管理されていなくて はならない –  仮想化はその第一歩 •  バージョン管理されていれば、以前のバージョンへの ロールバックも可能 解 決策
  • 17.
    1.3 もっとうまくできないのだろ うか? •  本書の目的→リリースをごく単純な作業に する •  開発環境、テスト環境、本番環境までど んなデプロイ対象にもボタンひとつでソフ トウェアをリリースできるようにする –  小規模な開発チームだけでなく、分散した チームによる大規模なエンタープライズプロ ジェクトでも実施できる
  • 18.
    1.4 どうすれば目標を達成できる か? •  目標:役に立って動作するソフトウェアをで きる限り素早くユーザに届けること •  サイクルタイムを減らす –  サイクルタイム:変更すると決めてからユーザが 使えるようになるまでの時間 –  機会損失を減らす/投資の回収を素早く開始する •  サイクルタイムを最小化し、(顧客からの)効 果的なフィードバックループを構築する => 素早いデリバリーが重要
  • 19.
    1.4 どうすれば目標を達成できる か? •  使い勝手おいて重要な部分を占めるのが品 質 •  品質を適切なレベルに保つことが重要 •  高品質で価値のあるソフトウェアを効率 的で素早く、信頼できるやり方でリリース する方法を見つけ出したい
  • 20.
    1.4 どうすれば目標を達成できる か? •  高品質で価値のあるソフトウェアを効率的で素早く、 信頼できるやり方でリリースする方法を見つけ出した い •  自動化 –  ビルド・デプロイ・テスト・リリースを自動化し、こまめ に繰り返す •  こまめに –  こまめなリリースによって、リリース間の差異を小さくす る => リリースリスクを小さく –  フィードバックを素早く得られるようにする
  • 21.
    1.4 どうすれば目標を達成できる か? •  フィードバック大事 –  あらゆる変更はフィードバックプロセスを引 き起こさなくてはならない –  フィードバックは早く伝えなくてはならない –  デリバリーチームはフィードバックを受け取 り、それに対して行動を起こさなければなら ない ここで言っているフィードバックとは   変更に対してテストを実行した結果のことも指し ている  
  • 22.
    1.4.1 あらゆる変更はフィードバックプロ セスを引き起こさなければならない •  ソフトウェアアプリケーションの4つの要 素 –  実行可能なコード –  設定 –  ホスト環境 –  データ •  どれかが変更されたら、そのせいでアプリ ケーションの振る舞いが変化する可能性が ある
  • 23.
    1.4.1 あらゆる変更はフィードバックプロ セスを引き起こさなければならない •  継続的インテグレーション(第3章で説明) •  実行可能コード –  あらゆる環境にデプロイされるものと同一で なければならない •  設定 –  環境ごとに変更される必要があるものは設定 情報として扱う必要がある –  設定変更されれば、どの環境であれテストし なければならない
  • 24.
    1.4.1 あらゆる変更はフィードバックプロ セスを引き起こさなければならない •  ホスト環境 –  環境に変更があれば、環境を変更した上でシ ステム全体をテストしなければならない –  環境とはOS、ソフトウェア(ミドルウェア)、 ネットワーク構成、あらゆる基盤や外部シス テムが含まれる •  データ –  データ構造が変更されたらテストしなければ ならない(データ管理については12章)
  • 25.
    1.4.1 あらゆる変更はフィードバックプロ セスを引き起こさなければならない •  変更時のフィードバックプロセス –  前述した各種テスト –  受け入れテスト、非機能要件テスト –  顧客に対するデモンストレーション •  できる限り完全に自動化されたテストの 実施 => フィードバックプロセスを引き起こす
  • 26.
    1.4.2 フィードバックはできる限 り早く受けとらなければならない •  素早いフィードバックの鍵は自動化 –  プロセスが完全に自動化されていればハード ウェアを投入すればいくらでもスケールする –  繰り返し作業は機械に任せる => 人的リソースの用途を最適化する
  • 27.
    1.4.3 デリバリーチームはフィードバックを受け 取り、それに対応しなければならない •  デリバリーチームがフィードバックプロセ スに関わっていることが重要 –  頻繁に会うことで、デリバリープロセスの改 善につながる •  フィードバックに対応できる => 情報を広くつたえることに繋がる •  フィードバックに対して、チーム全体の責 任として対処する
  • 28.
    1.4.4 このプロセスはスケールす るのか? •  小さいチームでしかうまくいかない? => NO! 大小様々なプロジェクトで実践 してきた方法について本書では解説してい る •  リーン生産方式の影響をうけている –  リーンは巨大な組織のために作られたもの –  リーンの理論やプラクティスは小さいチーム と同様に大きなチームにも当てはまる
  • 29.
    1.5 どんな恩恵を受けられるのか? •  反復可能で信頼でき、予測可能なリリース プロセスの構築 –  サイクルタイムの短縮 –  コストの節約 •  その他にも恩恵がある
  • 30.
    1.5.1 チームに権限を与える •  プルシステム –  テスターや運用担当者、サポート担当者が自 分の望むバージョンのアプリケーションを好 きな環境に自分でリリースできるようにする こと –  従来はこういった人達は「適正なビルド」が 提供されるのを待っていた => この待ちや手続きが非効率だった
  • 31.
    1.5.1 チームに権限を与える •  プルシステムによる恩恵の例 –  テスターは古いバージョンのアプリを選択して、 新しいバージョンにおける振る舞いの変更を検証 できる –  サポート担当者はリリースされたバージョンのア プリをテスト環境にデプロイして、欠陥を再現さ せることができる –  運用担当者はディザスタリカバリーの演習の一貫 として正しく動くとわかっているビルドを本番環 境にデプロイできる –  リリースがボタンひとつで実行できる
  • 32.
    1.5.1 チームに権限を与える •  チームメンバーは自分たちの仕事をコント ロールできるようになる •  仕事の品質が向上 •  アプリケーションの品質も向上 •  正しいビルドが渡されるのを待つ必要が なくなる
  • 33.
    1.5.2 エラーを削減する •  構成管理がまずいせいでエラーになる場合 について述べる •  (詳細は2章) •  構成管理は、典型的なアプリケーションを 動かすために適切に設定しなくてはなら ない
  • 34.
    1.5.2 エラーを削減する •  変化する可能性があるものをすべて、積極 的にバージョン管理で管理する –  設定ファイル/DBスキーマ生成スクリプト/ビ ルドスクリプト/テストハーネス/デプロイメ ント環境/OSの設定 •  設定の適用をコンピュータを使うように する(人力で適用しない)
  • 35.
    1.5.3 ストレスを低減する •  リリースのストレスからの開放! • まずは自動のデプロイメントプロセスを準 備しておく •  リリースまでにこまめに実行 •  変更前の状態に戻せるようにもしておく •  最初は痛みを伴うが、じょじょに簡単に なっていき、大きな恩恵が得られる
  • 36.
    1.5.4 デプロイメントの柔軟性 •  新環境でアプリを動かしはじめるという タスクはシンプルであるべき •  筐体や仮想イメージを作動させ、環境固有 の設定情報をつくるだけにしたい •  そこに自動化されたデプロイメントプロセ スを利用して環境構築&アプリのリリース を行う
  • 37.
    1.5.5 「できるようになりたけれ ば、練習しろ」 •  どこにデプロイする場合でも、デプロイ のアプローチを同一にする –  特別な受け入れテストとか本番用のデプロイ 戦略とかいうことがあってはいけない –  何回も本番にデプロイするのと同じ方法でデ プロイすることになる •  唯一例外が許されるのは開発環境のみ –  開発者が自分でバイナリをビルドする必要が あったりするので
  • 38.
    1.6 リリース候補 •  ビルドやデプロイの自動化が包括的な自動テ ストと併せて行われていれば、集中的で大々 的な手動テストは必要ない –  手動テストは機能を満たしていることを確認する だけでよい •  開発プロセス終了後にテストを実施すると品 質は低下する •  欠陥は素早く修正されるべき –  発見がおくれると修正にかかるコストは増加する
  • 39.
    1.6.1 あらゆるチェックインは潜 在的にリリースにつながる •  統合フェーズでまとめて統合を行う => 統合フェーズまできちんと動いている かわからない! 痛みが大きすぎる! •  こまめに統合する –  壊れたらすぐに修正 –  ソフトウェアは常に動く状態が保たれる –  常にリリースできる状態 –  継続的インテグレーションの第一のルール
  • 40.
    1.7 ソフトウェアデリバリーの原則 •  ソフトウェアをリリースするための、反復可能で 信頼できるプロセスを作り上げよ •  ほとんどすべてを自動化せよ •  すべてバージョン管理に入れよ •  痛みを伴うものはこまめに実施し、痛い思いは早 めにしておけ •  品質を作り込め •  完了したとはリリースしたということだ •  誰もがデリバリープロセスに対して責任を負う •  継続的改善
  • 41.
    1.7.1 ソフトウェアをリリースするための、反復 可能で信頼できるプロセスを作り上げよ •  リリースが簡単 => 何回も(リリースする) テストができる •  バージョン管理に端を発する完全に自動化 されたプロセスを作ることが重要
  • 42.
    1.7.2 ほとんどすべてを自動化せよ •  自動化できないものは多くはない –  人間の指示や意思決定が必要になるプロセス 直前までは自動化するべき –  受け入れテスト、DBのアップグレード/ダウ ングレード、ファイアウォールの設定も自動 化できる •  手作業のほうが簡単に思えるかもしれな いが、それを何回も繰り返すなら自動化 したほうが楽
  • 43.
    1.7.3 すべてバージョン管理にい れよ •  バージョン管理できるストレージにありとあ らゆる物を保管しなくてはならない –  要件定義ドキュメント、テストスクリプト、自動 テストのケース、ネットワーク構成スクリプト、 デプロイメントスクリプト、初期化スクリプト、 ツール群、ライブラリなどなどなど •  変更セットは単一の識別子を保つ必要がある •  新しいチームメンバーが新規の新しいマシン に座り、リポジトリからチェックアウトして、 コマンドを1行実行したらアプリケーション がビルドできる必要がある
  • 44.
    1.7.4 痛みを伴うものはこまめに実施 し、痛い思いは早めにしておけ •  最も役に立つ経験則 •  例) 統合はひどい苦痛を伴うプロセス => 誰かがチェックインするたびに統合を 行おう! プロジェクトの最初から •  とにかく苦痛と思うもの(リリース、結合、 テスト、などなど)はこまめに普段から自 動化して実施する
  • 45.
    1.7.5 品質をつくりこめ •  リーンからパクった原則 • 欠陥を早く見つけるほど、修正も安くあが る •  継続的インテグレーションで、欠陥を常に 検知できるようになった => すぐに修正できるようにする •  チームが品質に対する責任を負う
  • 46.
    1.7.6 完了したとはリリースした ということだ •  「完了した」とは価値をユーザに届けたとき –  外部のユーザに価値が届くまでは時間がかか る…… •  擬似本番環境にリリースし、ユーザコミュニ ティの代表者(プロダクトオーナーや依頼者) に対してデモを行い、触ってもらったときが 完了ということにしている •  80%完了などない。完了したか、してないか のみ
  • 47.
    1.7.7 誰もがデリバリープロセス に対して責任を負う •  縦割りだと責任のなすりつけ合いになる •  プロジェクトの最初から全員をデリバ リープロセスに巻き込む
  • 48.
    1.7.8 継続的改善 •  アプリケーションは進化していく => デリバリープロセスも一緒に進化する ことは重要 •  デリバリープロセスに関する振り返りを行 うべき •  組織内の誰もがPDCAサイクルに関わる –  壁を設けない。縦割りしない。犯人探しにな らないようにする
  • 49.
    1.8 まとめ •  ビルド・テスト・デプロイメントを自動化 する –  変更を確認できるようになる –  複数の環境にまたがってプロセスを再現でき るようになる –  本番にエラーが交じる可能性を大幅に低減で きる –  ビジネス上の利益を素早く提供できるように なる –  ワークライフバランスが改善される
  • 50.
    感想 •  同じ事繰り返し何度もいってるので辛い •  もっとまとめられそう •  この本を元に違う本が書けそう •  継続的デリバリー重要 •  宗教的 •  哲学的