Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,134 views

Published on

謎の集団『大崎的デリバリー』による継続的デリバリー読書会の第一回の資料です。

* 1章 : http://www.slideshare.net/chabudaigaeshi/1-13376219
* 2章: http://www.slideshare.net/kapara3/ss-13538343
* 3章: http://www.slideshare.net/norikazuhiraki/ss-14288316
* 4章: http://www.slideshare.net/favril1/continuous-delivery-chapter4
* 5章: http://www.slideshare.net/ts7i/5-14286065
* 6章: http://www.slideshare.net/ShinyaOzawa/continuous-delivery-6
* 7章: http://www.slideshare.net/Yanuto/7-14846466
* 8章: http://www.slideshare.net/shinjiyoshida/8-15631642
* 9章: http://www.slideshare.net/LagerKorone/continuous-delivery9
* 10章:(抜け)
* 11章: http://www.slideshare.net/chabudaigaeshi/ppt-16990236
* 12章: http://www.slideshare.net/shinjiyoshida/12-17792780
* 13章: http://www.slideshare.net/favril1/continuous-delivery-chapter13-18470451
* 14章: http://www.slideshare.net/chabudaigaeshi/14-20842590
* 15章: http://www.slideshare.net/ShinyaOzawa/continuous-delivery-15

Published in: Technology
  • Be the first to comment

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

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

×