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

『継続的デリバリー』読書会
第一章
ソフトウェアデリバリーの問題
大崎的デリバリー
@hidesuke

1.1 導入
この本の目的
•  本書の焦点
–  ビルド、デプロイ、テスト、リリースプロセ
ス
–  安全で信頼でき、素早くソフトウェアをリ
リースできるようにする
•  ソフトウェアの開発からリリースまで効率
的にすすめるためのパターンを解説する

1.1 導入
デプロイメントパイプライン
•  ビルド・デプロイ・テスト・リリースと
いったプロセスを自動化する実装
•  リリースする際の「価値の流れ（バリュー
ストリーム）」は組織によって異なる
–  組織毎に独自のデプロイメントパイプライン
を実装
–  どの組織でも原則は同じ

1.1導入
デプロイメントパイプラインの例

自動化された自動化された
コミットステー手作業でのテ
受け入れテスキャパシティリリース
ジ
スト
ト
テスト

1.1導入
デプロイメントパイプライン
•  継続的インテグレーション(CI)のプロセ
スが基礎となっている
–  CIの考え方を論理的に突き詰めたもの
•  3つの目的
–  見える化し共同作業をやりやすくする
–  早い段階での問題特定/解決の手助け
–  任意のバージョンのソフトウェアを任意の環
境に完全に自動化されたプロセスを通して好
きなようにデプロイできるようにする

1.2 リリースによくあるアンチパ
ターン
•  リリース日 => 緊迫した空気
–  プロセスが原因でリリースが恐ろしいものに
•  リリースのよくある風景
–  手作業
–  集中力が必要
–  各ホストに手作業でソフトウェアをセット
アップ
–  構成要素を１つずつ手動でたちあげ

1.2 リリースによくあるアンチパ
ターン
•  間違える可能性のある要素が多すぎる
•  一つでも間違えばアプリケーションは動か
ない

1.2.1 アンチパターン：ソフト
ウェアを手作業でデプロイする
•  広範囲にわたる詳細な手順書
–  必要なステップが全て記述してある
–  でも、リリース中に頻繁に修正
•  手動テストで動作確認
•  開発チームにデプロイがうまくいかない理由ついて頻
繁に問い合わせ
•  クラスタ内に設定の異なるノードがある
•  数分単位でリリースが終わらない
•  リリースの結果が予測できない
–  リリース前状態への切り戻し
–  不測の問題に行き当たる

•  帰れない
チパターン
アン

•  デプロイは完全に自動化するべき
•  人間がやるべきことは２つ
–  どのバージョンをどの環境にデプロイするか
を選択する
–  デプロイボタンを押す

解決策

•  自動化しないといけない
–  手動だとエラーがおきる
–  手動だと反復可能にならない、信頼できない。デ
プロイで起こったエラーのバグに時間がとられる
–  手順書を作らなくてよくなる
–  デプロイスクリプトがあれば自動化できる
•  デプロイをうまくやるためにデプロイスクリプトは常
にメンテナンスされる
•  共同作業が促進される
–  デプロイメント職人が不要になる解決策

1.2.2 アンチパターン：開発が終わっ
てから擬似本番環境にデプロイする
•  ステージングへのデプロイが必要になったと
きに、初めてデプロイチームが招集される
–  デプロイに必要なステップはステージング環境で
テストされないことが多い
–  ドキュメントが重要なステップを抜かしてる可能
性
–  ドキュメントやスクリプト上の想定が誤っていて、
デプロイに失敗
–  開発チームと協力していないので、失敗の原因を
当て推量ン
ンチパター
ア

•  ステージングに最初にデプロイするときが最
もトラブルが多い
•  リリースサイクルが長くなるほど、デプロイ
の前に行う想定は不正確になり、修正に時間
がかかる
•  大きな組織で、役割毎に組織が縦割りになっ
ている場合、申請書提出地獄になる
•  開発環境と本番環境の違いが大きいほど、想
定も現実と乖離する
–  Windows機上でSolarisクラスタにデプロイする
アプリを開発してるとか
チパターン
アン

•  テスト・デプロイ・リリースを開発プロセ
ス中に統合する
•  リリースを行うチーム、テスター、開発者
まで全員がプロジェクトの最初から確実
に協力しあう
•  ソフトウェアとデプロイプロセスの両方
をテストする

解決策

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

•  本番環境の構成管理を運用担当チームで行
なっている場合……
–  本番サーバに対して手作業で変更が行われる
•  データベース接続設定とか
–  変更の記録が変更管理DBに残される

•  ステージングへのデプロイは何度も成功して
るけど、本番へのデプロイで失敗する
•  クラスタ内の別々のメンバで振る舞いが違う
–  他のメンバだと耐えられる負荷に耐えられない子
がいる
–  処理に時間がかかる子がいる
•  運用チームがリリースのために時間がかかる
•  システムを以前の状態に戻せない
•  クラスタ内でバージョンが統一されていない
•  本番を直接編集で設定を修正

チパターン
アン

•  設定などは自動プロセスを通じてバージョン管理から
適用されるべき
–  テスト環境、ステージング環境、本番環境のあらゆる設定
–  特にサードパーティーの要素の設定
•  構成管理にはあらゆる構成要素を繰り返し再現できる
ということも含まれる
–  OS、パッチレベル、OSの設置、アプリケーションスタッ
クとその設定、基盤設定など、全てが管理されていなくて
はならない
–  仮想化はその第一歩
•  バージョン管理されていれば、以前のバージョンへの
ロールバックも可能
解決策

1.3 もっとうまくできないのだろ
うか？
•  本書の目的→リリースをごく単純な作業に
する
•  開発環境、テスト環境、本番環境までど
んなデプロイ対象にもボタンひとつでソフ
トウェアをリリースできるようにする
–  小規模な開発チームだけでなく、分散した
チームによる大規模なエンタープライズプロ
ジェクトでも実施できる

1.4 どうすれば目標を達成できる
か？
•  目標：役に立って動作するソフトウェアをで
きる限り素早くユーザに届けること
•  サイクルタイムを減らす
–  サイクルタイム：変更すると決めてからユーザが
使えるようになるまでの時間
–  機会損失を減らす/投資の回収を素早く開始する
•  サイクルタイムを最小化し、(顧客からの)効
果的なフィードバックループを構築する
=> 素早いデリバリーが重要

か？
•  使い勝手おいて重要な部分を占めるのが品
質
•  品質を適切なレベルに保つことが重要

•  高品質で価値のあるソフトウェアを効率
的で素早く、信頼できるやり方でリリース
する方法を見つけ出したい

か？
•  高品質で価値のあるソフトウェアを効率的で素早く、
信頼できるやり方でリリースする方法を見つけ出した
い

•  自動化
–  ビルド・デプロイ・テスト・リリースを自動化し、こまめ
に繰り返す
•  こまめに
–  こまめなリリースによって、リリース間の差異を小さくす
る
=> リリースリスクを小さく
–  フィードバックを素早く得られるようにする

か？
•  フィードバック大事
–  あらゆる変更はフィードバックプロセスを引
き起こさなくてはならない
–  フィードバックは早く伝えなくてはならない
–  デリバリーチームはフィードバックを受け取
り、それに対して行動を起こさなければなら
ない

ここで言っているフィードバックとは

変更に対してテストを実行した結果のことも指し
ている

1.4.1 あらゆる変更はフィードバックプロ
セスを引き起こさなければならない
•  ソフトウェアアプリケーションの4つの要
素
–  実行可能なコード
–  設定
–  ホスト環境
–  データ
•  どれかが変更されたら、そのせいでアプリ
ケーションの振る舞いが変化する可能性が
ある

•  継続的インテグレーション(第3章で説明)
•  実行可能コード
–  あらゆる環境にデプロイされるものと同一で
なければならない
•  設定
–  環境ごとに変更される必要があるものは設定
情報として扱う必要がある
–  設定変更されれば、どの環境であれテストし
なければならない

•  ホスト環境
–  環境に変更があれば、環境を変更した上でシ
ステム全体をテストしなければならない
–  環境とはOS、ソフトウェア(ミドルウェア)、
ネットワーク構成、あらゆる基盤や外部シス
テムが含まれる
•  データ
–  データ構造が変更されたらテストしなければ
ならない(データ管理については12章)

•  変更時のフィードバックプロセス
–  前述した各種テスト
–  受け入れテスト、非機能要件テスト
–  顧客に対するデモンストレーション
•  できる限り完全に自動化されたテストの
実施
=> フィードバックプロセスを引き起こす

1.4.2 フィードバックはできる限
り早く受けとらなければならない
•  素早いフィードバックの鍵は自動化
–  プロセスが完全に自動化されていればハード
ウェアを投入すればいくらでもスケールする
–  繰り返し作業は機械に任せる
=> 人的リソースの用途を最適化する

1.4.3 デリバリーチームはフィードバックを受け
取り、それに対応しなければならない

•  デリバリーチームがフィードバックプロセ
スに関わっていることが重要
–  頻繁に会うことで、デリバリープロセスの改
善につながる
•  フィードバックに対応できる
=> 情報を広くつたえることに繋がる
•  フィードバックに対して、チーム全体の責
任として対処する

1.4.4 このプロセスはスケールす
るのか？
•  小さいチームでしかうまくいかない？
=> NO! 大小様々なプロジェクトで実践
してきた方法について本書では解説してい
る
•  リーン生産方式の影響をうけている
–  リーンは巨大な組織のために作られたもの
–  リーンの理論やプラクティスは小さいチーム
と同様に大きなチームにも当てはまる

1.5 どんな恩恵を受けられるのか？

•  反復可能で信頼でき、予測可能なリリース
プロセスの構築
–  サイクルタイムの短縮
–  コストの節約
•  その他にも恩恵がある

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (11)

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

Similaire à 継続的デリバリー読書会資料 #1 (20)

Plus de Yusuke HIDESHIMA

Plus de Yusuke HIDESHIMA (9)

Dernier

Dernier (10)

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