Downloaded 28 times
Uploaded byYusuke HIDESHIMA
継続的デリバリー読書会資料 #1
謎の集団『大崎的デリバリー』による継続的デリバリー読書会の第一回の資料です。 * 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
継続的デリバリー読書会資料 #1
- 1. 『継続的デリバリー』読書会 第一章 ソフトウェアデリバリーの問題 大崎的デリバリー @hidesuke
- 2. 1.1 導入 この本の目的 • 本書の焦点 – ビルド、デプロイ、テスト、リリースプロセ ス – 安全で信頼でき、素早くソフトウェアをリ リースできるようにする • ソフトウェアの開発からリリースまで効率 的にすすめるためのパターンを解説する
- 3. 1.1 導入 デプロイメントパイプライン • ビルド・デプロイ・テスト・リリースと いったプロセスを自動化する実装 • リリースする際の「価値の流れ（バリュー ストリーム）」は組織によって異なる – 組織毎に独自のデプロイメントパイプライン を実装 – どの組織でも原則は同じ
- 4. 1.1導入 デプロイメントパイプラインの例 自動化された 自動化された コミットステー 手作業でのテ 受け入れテス キャパシティ リリース ジ スト ト テスト
- 5. 1.1導入 デプロイメントパイプライン • 継続的インテグレーション(CI)のプロセ スが基礎となっている – CIの考え方を論理的に突き詰めたもの • 3つの目的 – 見える化し共同作業をやりやすくする – 早い段階での問題特定/解決の手助け – 任意のバージョンのソフトウェアを任意の環 境に完全に自動化されたプロセスを通して好 きなようにデプロイできるようにする
- 6. 1.2 リリースによくあるアンチパ ターン • リリース日 => 緊迫した空気 – プロセスが原因でリリースが恐ろしいものに • リリースのよくある風景 – 手作業 – 集中力が必要 – 各ホストに手作業でソフトウェアをセット アップ – 構成要素を１つずつ手動でたちあげ
- 7. 1.2 リリースによくあるアンチパ ターン • 間違える可能性のある要素が多すぎる • 一つでも間違えばアプリケーションは動か ない
- 8. 1.2.1 アンチパターン：ソフト ウェアを手作業でデプロイする • 広範囲にわたる詳細な手順書 – 必要なステップが全て記述してある – でも、リリース中に頻繁に修正 • 手動テストで動作確認 • 開発チームにデプロイがうまくいかない理由ついて頻 繁に問い合わせ • クラスタ内に設定の異なるノードがある • 数分単位でリリースが終わらない • リリースの結果が予測できない – リリース前状態への切り戻し – 不測の問題に行き当たる • 帰れない チパ ターン アン
- 9. 1.2.1 アンチパターン：ソフト ウェアを手作業でデプロイする • デプロイは完全に自動化するべき • 人間がやるべきことは２つ – どのバージョンをどの環境にデプロイするか を選択する – デプロイボタンを押す 解 決策
- 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. 感想 • 同じ事繰り返し何度もいってるので辛い • もっとまとめられそう • この本を元に違う本が書けそう • 継続的デリバリー重要 • 宗教的 • 哲学的