『継続的デリバリー』 第15章 学習メモ
継続的デリバリーの管理の概観
1.はじめに
継続的デリバリーにおける、継続的デリバリーの管理についての調査記録です。
継続的デリバリーの中での、継続的デリバリーの管理についての概観を記載します。
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』の第15章に対応します。
2.概要・目的
継続的デリバリーの管理の観点は以下の通り。
- 継続的デリバリーはソフトウェアビジネスを前進させるための新しいパラダイム
- コーポレートガバナンス（適合性）とビジネスガバナンス（パフォーマンス・業績）の対立
- デプロイメントパイプラインの作用
- コーポレートガバナンスのための透過性
- ビジネスガバナンスのためのフィードバック
- インクリメンタルなデリバリー
- 自動化による信頼性の向上
- 素早く信頼できるリリース
- リスクやコストの削減
3.対応概要
構成管理とリリース管理のためのステータスモデルは以下を示す。
- プロジェクトの検証の方法、検証のための観点
ソフトウェアデリバリーのライフサイクルの観点は以下の通り。
- 発見期
- ステークホルダーの特定
- 開始期
- 問題解決をステークホルダー間で共有
- 構築期
- 最もシンプルなストーリーに対して、以下を実証
- バージョン管理
- CIでのテスト
- 手動テスト
- 環境へのデプロイ
- 最もシンプルなストーリーに対して、以下を実証
- 開発・リリース期
- イテレーティブでインクリメンタルなプロセスの規範の適用とそれによる作用
- 運用期
- 開発・リリース期と同じく、新たな機能の追加でも、分析・開発・テスト・リリースのプロセスとする
- データ管理のみ異なる
4.対応詳細
(1)リスク管理プロセス
リスク管理プロセスの観点は以下の通り。
(2)デリバリーによくある問題
デリバリーによくある問題として以下が挙げられる。
- 頻度の低いデプロイメント・バグのあるデプロイメント
- 貧弱な品質
- 管理が貧弱なCIプロセス
- 貧弱な構成管理
(3)コンプライアンスと監査
デプロイメントパイプラインの規制への準拠の観点は以下の通り。
- 自動化
- トレーサビリティ
- 観察・分析の共有
- 変更の管理
- 承認プロセス
5.影響・作用
管理作業により、ソフトウェアのデリバリーを効率的に行いつつリスク管理も適切に行い、規制制度にも準拠できる。
6.おわりに
以上が、継続的デリバリーの中での、継続的デリバリーの管理についての概観です。
7.参考文献
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』 第15章 継続的デリバリーを管理する
『継続的デリバリー』 第14章 学習メモ
バージョン管理の概観
1.はじめに
継続的デリバリーにおける、バージョン管理についての調査記録です。
継続的デリバリーの中での、バージョン管理についての概観を記載します。
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』の第14章に対応します。
2.概要・目的
バージョン管理は、すべての変更の履歴を管理し、複数チームで開発するアプリケーション全体のコードベースを管理する。
3.背景
リビジョンとは、ディレクトリ群の中にある変更されたファイルのセットで構成されたもの。チェンジセットとも言う。 各リビジョンにはリポジトリ内の全ファイルの、ある特定の時点のスナップショットが含まれている。 リビジョン管理システムの歴史についての観点は以下の通り。
- CVSにあった問題
- SVNによる解決
- 商用のバージョン管理システム
- 〇楽観的ロック/×悲観的ロック
- 衝突の解消
4.対応概要
(1)ブランチとマージ
ブランチとマージの分析の観点は以下の通り。
- コードラインポリシー
- マージの問題
- リリースブランチ以外を作らないことの作用→CI
(2)メインラインでの開発
メインライン上での開発の観点は以下の通り。
- 高速フィードバックによりほぼ常にリリース可能な状態。
- メインライン上での開発のCIへの作用
- 不要ブランチの回避
- 抽象化によるブランチパターンの適用
5.対応詳細
(1)分散バージョン管理システム
分散バージョン管理システムの観点は以下の通り。
- 分散バージョン管理システムの作用
- コミット権のボトルネックの解消
- 分散バージョン管理システムの歴史
- 分散バージョン管理システムのCIへの対応
- 企業環境にも対応するための多くの機能を持つ
- 分散バージョン管理システムの使い方と作用
(2)ストリームベースのバージョン管理システム
ストリームベースのバージョン管理システムの観点は以下の通り。
- 「継承」が可能
- 問題：CI・CDへの違反
- Gitなどの分散バージョン管理システムで解決可能
- 静的ビューと動的ビュー
- 問題：速度とロールバック
(3)ブランチ
ブランチの観点は以下の通り。
- リリース用のブランチが解決する問題
- フィーチャーブランチのCIに対する問題と対応
- オープンソースソフトウェアで十分に制約を満たしたときのみ機能する
- チームブランチ≒フィーチャーブランチ
- 以下のような条件が揃って初めて、疎結合なコンポーネントへの移行に使える
- 分散バージョン管理システムの機能
- インクリメンタルな開発
- カプセル化
- 以下のような条件が揃って初めて、疎結合なコンポーネントへの移行に使える
6.影響・作用
バージョン管理のパターンがデプロイメントパイプラインの設計の重要なポイントとなる。
バージョン管理によって素早くローリスクなリリースが可能となる。
7.おわりに
以上が、継続的デリバリーの中での、コミットステージについての概観です。
8.参考文献
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』 第14章 高度なバージョン管理
『継続的デリバリー』 第13章 学習メモ
コンポーネントや依存関係の管理の概観
1.はじめに
継続的デリバリーにおける、コンポーネントや依存関係の管理についての調査記録です。
継続的デリバリーの中での、コンポーネントや依存関係の管理についての概観を記載します。
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』の第13章に対応します。
2.概要・目的
コンポーネントベースのシステムは以下の特徴を持つ。
- いくつかの部品に分割できる
- 明確に定義された振る舞いを持つ、同じAPIを持つ別のコンポーネントで代替可能
- 他のコンポーネントと最小限のやりとりをする
- カプセル化がされており、一枚岩のシステムの対極である
コンポーネントベースの設計により、以下の恩恵を得られる。
コンポーネントや依存関係を管理することで、以下の、ビルドシステムにおける3つの自由を得られる。
- デプロイメントパイプライン
- ブランチ
- コンポーネント
3.対応概要
アプリケーションをリリース可能な状態に保つための観点は以下の通り。
- メインラインでの開発
- メインラインで開発しながら常にリリース可能にするための解決策
- 新機能は完成するまで隠す
- すべての変更はインクリメンタルに行い、個々の変更をリリース可能な状態にする
- 抽象化によるブランチで、大規模な変更をコードベースに加える
- 変更の頻度が異なる部分をコンポーネント化して、アプリケーションから切り離す
4.対応詳細
(1)依存関係の管理
依存関係の管理の観点は以下の通り。
- コンポーネントとライブラリの区別
- ライブラリ：通常めったに更新されない
- コンポーネント：ソフトウェアの部品としてアプリケーションが依存しているもので、自分たち（または同一組織のチーム）が頻繁に更新する。
- ビルド時の依存関係と実行時の依存関係の区別
- ビルド時：アプリケーションをコンパイルし（必要なら）リンクするときにあらわれるもの
- 実行時：アプリケーションを実行して通常の機能を実行するときにあらわれるもの
- 依存地獄
- ライブラリの管理
- ライブラリのバージョン管理の方法と問題
- ビルドの再現性
- 自前の成果物リポジトリ
- 宣言的な依存管理の自作
(2)コンポーネント
コンポーネントの観点は以下の通り。
- コードベースをコンポーネントに分割
- コンポーネントのパイプライン化
- パイプラインの分割が解決する問題
- 並列パイプラインの方法と欠点
- パイプラインの分割が解決する問題
- インテグレーションパイプライン
- 高速フィードバック
- 各パイプラインからの可視性
- 組み合わせたときの問題
(3)依存グラフの管理
依存グラフの管理の観点は以下の通り。
- 依存関係のバージョン管理
- 無閉路有向グラフ
依存グラフの作成
- ひし形依存の問題
- 高速フィードバックのための解決策
- 依存グラフをパイプライン化
- 可視性のための解決策
- コンポーネント分割によるリリースブランチ許容の例外
- ビルドのタイミング
- コンポーネント更新の判断基準
- 新バージョンの統合作業を継続的に行い、素早いフィードバックを得る
- コンポーネント更新の判断基準
- 依存グラフへの状態の追加
- 浅い依存グラフと後方互換性による依存関係の単純化
- 循環依存
(4)バイナリの管理
バイナリの管理の観点は以下の通り。
- 成果物リポジトリ
- 再生成可能なもののみ格納し、削除を可能にする
- ハッシュの保持
- バイナリとソースの紐づけ
- インデックスファイルの追加
(5)Mavenでの依存関係の解決例
Mavenでの依存関係の解決例での観点は以下の通り。
- 依存関係のキャッシュ
- 成果物の保存
- バージョンの指定
- スコープの指定
- 依存関係の重複排除
5.影響・作用
インクリメンタルな変更とメインラインへのチェックイン、またはアプリケーション自体をコンポーネントに分割することで、素早いフィードバックを得られる。
6.おわりに
以上が、継続的デリバリーの中での、コンポーネントや依存関係の管理についての概観です。
7.参考文献
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』 第13章 コンポーネントや依存関係を管理する
『継続的デリバリー』 第12章 学習メモ
データ管理の概観
1.はじめに
継続的デリバリーにおける、データ管理についての調査記録です。
継続的デリバリーの中での、データ管理についての概観を記載します。
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』の第12章に対応します。
2.概要・目的
データを管理するとき、テストやデプロイメントのプロセスでいくつか問題が生じる。その理由は以下の2点である。
- データの量
- アプリケーションのデータとシステムの他の部分とではライフサイクルが異なる
データの構造や内容を変更する必要がある場合の問題に対応する。
混乱を最小化し、アプリケーションやデプロイメント処理の信頼性を最大化する仕組みのために、DBの移行プロセスを自動化する。
自動化した内容はスクリプトにして自動デプロイメントプロセスに組み込む。
3.対応概要
(1)DBのスクリプト処理
DBのスクリプト処理の観点は以下の通り。
- 初期化スクリプト、初期化の手順
- DBのバージョン管理
(2)データの管理とデプロイメントパイプライン
各テストステージにおけるデータの観点は以下の通り。
- コミットテストステージ
- テストヘルパーやフィクスチャによるデータ作成の再利用
- 受入テストステージ
- データの分類
- テストケース作成の再利用
- データへの依存の最小化
- アプリケーションのAPIの使用の作用
- キャパシティテストステージなど
- 受入テストのインタラクションを記録し、キャパシティテストなど以後のテストに使用する
- 手動テスト
- 空の状態で立ち上げるか、カスタマイズしたデータ群の使用がよい
4.対応詳細
(1)DBのロールバックとゼロダウンタイムリリース
DBのロールバックとゼロダウンタイムリリースの観点は以下の通り。
(2)テストデータ管理
テストデータの管理の観点は以下の通り。
- テストデータ管理の要件・機能
- パフォーマンス
- テストの分離
- ユニットテストにおけるDB
- テストとデータの関連の整理
5.影響・作用
以上の対応により、完全に自動化したプロセスでDBの作成やマイグレーションを行えるようにする。
6.おわりに
以上が、継続的デリバリーの中での、データの管理についての概観です。
7.参考文献
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』 第12章 データを管理する
『継続的デリバリー』 第11章 学習メモ
基盤と環境の管理のための概観
1.はじめに
継続的デリバリーにおける、基盤と環境の管理についての調査記録です。
継続的デリバリーの中での、基盤と環境の管理のための概観を記載します。
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』の第11章に対応します。
2.概要・目的
目標は、すべてのテスト環境を本番環境と同様の方法で扱うこと。
環境とは、アプリケーションの動作や設定に必要となるすべてのリソースのこと。
環境は、以下の特性を持つものである。
- 環境を構成するサーバのハードウェア構成、およびサーバが接続するネットワーク基盤
- OSやミドルウェアの設定が、アプリケーションの動作のために必要
包括的な手法ですべての基盤を管理するための原則は以下の3点である。
- 基盤に要求される状態は、バージョン管理された設定で指定する
- 基盤は要求された状態に自動的に持ち込む（自動化）
- 基盤の状態を監視する
デプロイのリスクを軽減するために管理すべき項目は以下の通り。
- OSおよびその設定
- MW（ミドルウェア）スタックおよびその設定
- 基盤管理用ソフトウェア
- 外部の統合ポイント
- ネットワーク基盤
- アプリケーション開発チームと基盤管理チームの関係
また、基本原則として、テスト環境は本番環境にできるだけ近づけ、環境の問題を早期発見する。
これにより、あいまいで再現性の低い設定や統合時の問題を早期発見できる。
3.問題・要求
運用上の要求についての観点は以下の通り。
- MTBF,MTTR,SLA
- 文書化と監査
- 異常発生警告
- エラーは1か所にまとめてログを残す。深刻度も記録する
- 監視方法もアプリケーションの機能として扱う
- 業務継続性
- デプロイメントシステムの技術の決定
4.対応概要
基盤のモデリング・管理についての観点は以下の通り。
- 構成情報の準備や管理の自動化
- 自動化しやすい技術の選択。以下は自動化のための観点
- 基盤のプロビジョニング
- 基盤を構成する様々なソフトウェアのデプロイメントや設定
- プロビジョニングや設定を済ませた基盤の管理
- 必要となるマルチユーザアプリケーションの設定
- OS
- ミドルウェア
- DB
- ユーザ
- アプリケーションのデプロイメント
- メッセージの登録
- バージョン管理の対象。デプロイメントパイプラインへの入力
- OSのインストール定義
- データセンター自動化ツール
- 基盤の設定
- 基盤管理のためのスクリプト
- 基盤の変更後のデプロイメントパイプライン
- 依存の規則
- 変更の共有と個別のパイプライン
5.対応詳細
(1)基盤へのアクセス制御
基盤へのアクセス制御の観点は以下の通り。
(2)サーバのプロビジョニングと設定の管理
サーバのプロビジョニングと設定の管理の観点は以下の通り。
- プロビジョニングの手順
- 進行中のサーバ管理
(3)ミドルウェアの構成管理
ミドルウェアの構成管理の観点は以下の通り。
- Webサーバ・メッセージングシステム・商用パッケージソフトウェアなどのミドルウェアは以下の3点で構成される
- バイナリ
- 設定
- データ
- 以下のいずれかの方法で設定を管理
- PuppetやSCCMなどでOSと同様に管理
- OSのパッケージ管理システムでパッケージを作成
- 設定をスクリプトで管理できるミドルウェアを使い、デプロイメントや設定を自動化
- 製品が持つ自動化された設定オプションの調査
- 設定APIの使用
- より良いソリューションを探す
(4)基盤サービスの管理
基盤サービスの管理の観点は以下の通り。
- ネットワーク基盤の設定のバージョン管理
- ネットワーク監視システムの使用
- アプリケーションでのネットワークについてのログの記録
- スモークテスト
- ネットワークトポロジーを本番環境に合わせる
- 問題の調査のためのフォレンジックツール
- マルチホームシステムにおけるNICの分離と管理
(5)仮想化
仮想化の観点は以下の通り。
- 仮想化の作用
- 新しい環境の保守やプロビジョニングの容易さ
- 非機能要件のテストの容易さ
- テストの並列実行
- 仮想環境管理の方法
- データセンター自動化ツールの使用
- 仮想化技術のデプロイメントパイプラインへの適用
- ビルドシステム・リリース管理システムによる仮想マシンテンプレートセットの記録
- ベースラインイメージの保持
- 並列化したテスト
- マルチプラットフォーム対応
- 自動キャパシティテストの高速化
- 仮想ネットワーク
(6)クラウドコンピューティング
クラウドコンピューティングの観点は以下の通り。
- 利点と分類
- クラウド基盤における以下への対応と限界
- セキュリティ
- コンプライアンス
- サービスレベル
- プラットフォームのクラウド化の作用と制約
- クラウドコンピューティングの分析と批判
(7)基盤やアプリケーションの監視
基盤やアプリケーションの監視の観点は以下の通り。
- 以下の項目への作用
- ビジネス
- 運用
- プロジェクト
- 以下の機能が必要となる
- 収集
- 保持
- 可視化
- 通知
- 収集の対象とツール
- ログの出力
- 表示するレベルの設定
- 運用チームのための機能
- 網羅性と可読性
- 可視化
- テストファーストの監視
6.影響・作用・まとめ
コストの分析して戦略を適用することで、アプリケーションを使い続ける間ずっと手動で環境を管理するよりもコストを削減できる。
サードパーティ製品の評価には、自動化した構成管理への適応性を観点とする。
7.おわりに
以上が、継続的デリバリーの中での、コミットステージについての概観です。
8.参考文献
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』 第11章 基盤と環境を管理する
『継続的デリバリー』 第10章 学習メモ
アプリケーションのデプロイ・リリースの概観
1.はじめに
継続的デリバリーにおける、アプリケーションのデプロイ・リリースについての調査記録です。
継続的デリバリーの中での、アプリケーションのデプロイ・リリースについての概観を記載します。
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』の第10章に対応します。
2.概要・目的
デプロイメントとリリースの差異は、設定ファイルなどにカプセル化する必要がある。
デプロイメントとリリースの主な違いは、ロールバックの方法である。
すべての環境に対するあらゆる変更の適用のために唯一使える仕組みを提供する。
3.対応概要
(1)リリース戦略の作成
リリース戦略の作成の観点は以下の通り。
- プロジェクト開始時での決定事項
- リリース計画時での決定事項
- 商品化のための決定事項
(2)デプロイ
デプロイのための観点は以下の通り。
- 最初のデプロイ
- 下準備用のイテレーション
- 疑似本番環境のための仮想化・チキンカウント
- 疑似本番環境の特徴
- リリースプロセス（自動ステージ後のビルドの扱い）のモデル化
- ビルドの反映
- テストステージのワークフロー
- 設定の反映の検証のためのスモークテスト・監視ツール
- サービス・コンポーネントの組み合わせをまとめて反映する
- オーケストレーション
- OS・ミドルウェアの設定
- IT
- スモークテスト
- ステージング環境へのデプロイメント
4.対応詳細
ロールバックの制約は以下の2つ。
- データ
- 複数システムの統合
ロールバックの原則は以下の2つ。
- 本番システムをバックアップしてからリリース作業に入る
- 作成した計画に基づいてロールバックを試行する
- 直近の正常動作するバージョンの再デプロイによるロールバックの是非
- ゼロダウンタイムリリースにおけるリリースプロセスの疎結合か
- ブルーグリーンデプロイメント
- DBとコストへの対応が必要
- カナリアリリースの機能と作用
- 緊急修正時の規範
- 継続的デプロイメントを可能にするデプロイメントパイプライン
- ユーザがインストールするソフトウェアの継続的リリース
- 自動更新がよい
- バックアップ
- 移行スクリプト
- クラッシュレポート
デプロイメントのためのヒントや裏技は以下の通り。
- 自動化できていない部分のデプロイメント作業の記録
- 古いファイルは削除せず移動する
- システムのウォームアップ
- スモークテスト
- 本番環境へのアクセス制限
5.影響・作用
リリースはプロジェクト全体で初期から継続的な改善が必要。
共同作業で、より効率的なデリバリープロセスを構築する。
6.おわりに
以上が、継続的デリバリーの中での、アプリケーションのデプロイ・リリースについての概観です。
7.参考文献
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』 第10章 アプリケーションをデプロイ・リリースする
『継続的デリバリー』 第9章 学習メモ
非機能テストの概観
1.はじめに
継続的デリバリーにおける、非機能テストについての調査記録です。
継続的デリバリーの中での、非機能テストについての概観を記載します。
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』の第9章に対応します。
2.概要・目的
非機能要件の中でも、特に以下を重点として扱う。
- パフォーマンス：単一のトランザクションの処理に要する時間
- スループット：一定の期間内にシステムが処理できるトランザクションの数
- キャパシティ：一定の負荷がかかった状態で個々のリクエストを許容範囲のレスポンスでさばききれる最大のスループット
非機能要件は、ソフトウェアデリバリーに関する重大なリスクとなる。
非機能要件は、システム特性とも呼ぶ。
どの非機能要件が重要なのかをプロジェクトの開始時に見つけることが重要。
非機能要件をデリバリースケジュールの中で定期的に計測する。
3.対応概要
非機能要件の分析の観点は以下の通り。
4.対応詳細
キャパシティを確保するためのプログラミングの観点は以下の通り。
キャパシティの計測手法の観点は以下の通り。
キャパシティテストの観点は以下の通り。
- カナリアリリース戦略の一環として実行
- 受入テストを引用し、規模を拡大。成功条件を設定して、システムに負荷をかける
- アプリケーションの記録と再生
- UI経由でのキャパシティテストを避ける
- サービスや公開APIへのインタラクションの記録
- キャパシティテスト用スタブ
- デプロイメントパイプラインにキャパシティテストを追加
キャパシティテストシステムは、実験用のリソースとなる。
5.影響・作用
非機能要件とは、現実の要件として検討する必要があるが、利用するユーザの考える要件とは異なるもの。
問題の観察や分析が重要であり、これにより、非機能要件の受け入れ基準を、機能要件と同様に設定できるようになる。
受入テストを元にした、より広範囲なシナリオベースのテストで非機能要件を検証することで、システムの特性を包括的で保守可能な形式で維持することができる。
6.おわりに
以上が、継続的デリバリーの中での、非機能テストについての概観です。
7.参考文献
『継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』 第9章 非機能要件をテストする
