1. 『継続的デリバリー』読書会
第２章
構成管理
大崎的デリバリー
@kapara_c

2. 2.1
導入
構成管理の定義
• プロジェクトに関連するあらゆる成果物とそれ
らの間にある関係性が、保存され、検索され、
一意に特定され、修正されるプロセスのこと
である。

3. 2.1 導入
適切な構成管理とは
• あらゆる環境を再現できる
– OS
– パッチレベル
– ネットワーク構成
– ソフトウェアスタック
– デプロイされるアプリケーションとその設定
• インクリメンタルな変更を行い、他の環境に対して簡
単にデプロイできる

4. 2.1 導入
適切な構成管理とは
• 変更点を容易に確認できる
また、誰がいつ変更を行ったかを追跡できる
• コンプライアンスの規約をすべて満たす
• チームの全員が必要な情報を取得し、変更すること
ができる。
– チーム間に壁を作って、サイクルタイムが長くなり、フィー
ドバックが減ることになっていないか？

5. 2.2バージョン管理を使う
• バージョン管理システムを使う理由
– ソフトウェアの特定のバージョンを構成しているものを知り
たい
– いつ、誰が、何のために、何を行ったのかを把握できる
• チームが離れた場所、別の時間帯で作業しても協力できる

6. 2.2.1 ひとつ残らずすべてバージョン
管理に保存せよ
• ソースコード
• テスト、データベーススクリプト
• ビルド・デプロイメントスクリプト
• ドキュメント
• ライブラリ
• 設定ファイル
• テスト環境や本番環境を再現するのに必要な情報
アプリケーションのバイナリと実行環境を再現するのに必要な
すべてを保存する

7. 2.2.2 定期的にtrunkにチェックインせよ
• こまめにチェックインすることで、問題の解決を容易にするこ
とができる
• 機能毎にブランチを切る方法は、継続的インテグレーションと
は相容れない
– 機能の統合が先延ばしになる
– 複数のブランチを作ると問題はより複雑になる
– 統合に関わる問題がマージの時にしか発見されない
– マージツールも意味上の競合は解決してくれない
• チェックインの際にビルドを壊さないために
– チェックインの前にコミットテストを一式実行する
– 変更をインクリメンタルに行う

8. 2.2.3 意味のあるコミットメッセージを使え
• どんな変更をしたのかをきちんと説明するコミットメッセージ
を使うことで、後々何時間というデバッグをしなくて済む
• よりよいメッセージ
– １行目に要約を書く
– 以降の複数行にわたって詳細な説明を記述する
• コミットをプロジェクト管理ツールに紐付ける
– 紐付けができていないコミットが失敗するように

9. 2.3 依存関係の管理
2.3.1 外部ライブラリを管理する
• RubyGemsなどを使って特定のライブラリをダウン
ロードできるようにする
– リポジトリが肥大化しなくて済む
• 社内の共通リポジトリに外部ライブラリのコピーをお
いておく
– 新メンバーのスタートアップが楽になる
• どちらにしても、外部ライブラリの正確なバージョン
を常に指定しなければならない

10. 2.3.2 コンポーネントを管理する
• 一つのコンポーネントをビルドした場合に、依存関
係のあるコンポーネントのみリビルドして欲しい
• しかし、現実にはそんなことができるツールはない
• ビルドエンジニアが自前で依存関係を管理する必要
がある

11. 2.4 ソフトウェアを管理する
2.4.1 設定と柔軟性
• ソースに対する安全装置はいろいろあるが、設定に
対する安全装置はほとんどない
• 設定を柔軟にしようとするせいで分析麻痺に陥る
• システムが複雑になってしまい、柔軟性の恩恵が失
われてしまう
• スモークテストは設定によって起こる問題を和らげ
てくれる

12. 2.4.2 設定の種類
• 設定の種類にはいくつかある
– ビルド時の設定
– パッケージング時の設定
– デプロイメント時の設定
– 起動時や実行時の設定
• ビルド時やパッケージング時の設定は悪い設定
– あらゆる環境に同じバイナリをデプロイできるべき
• 設定情報は可能な限り同じ手段で提供されるべき

13. 2.4.3 アプリケーションの設定を管理する
設定にアクセスする
• ファイルシステム経由の管理
– あらゆる言語でサポートされる
– アプレットのようなものでは使えない
• Web経由で管理
• 設定にアクセスする際は、インターフェイスのみ公開
し、実装は隠蔽すること

14. 2.4.3 アプリケーションの設定を管理する
設定をモデリングする
• 設定情報はタプルの集合でモデル化される
• 設定情報は以下に依存する
– アプリケーション
– アプリケーションのバージョン
– アプリケーションの実行環境

15. 2.4.3 アプリケーションの設定を管理する
システム設定をテストする
• 外部サービスへの参照が適切であるかテストする
– 最低でもすべての外部サービスにpingを打つ程度は
– 依存しているサービスが一つでも動いてなければ落ちな
ければならない
• アプリケーションがインストールされた後で、いくつ
かスモークテストを行う
– 設定が正しいことに依存するテストをいくつか行う

16. 2.4.4 アプリケーションをまたいで設定を
管理する
• プロジェクトに関連する設定を一欄できるようにする
• 可能であれば設定を自動生成するように
• もしくはWikiなどに集約させる
• 動作しているアプリケーションの設定情報を監視シ
ステムを通じて見ることができるように

17. 2.4.5 アプリケーション構成管理の原則
• 設定オプションはソースコードと同じレポジトリで管理する。た
だし、値は別の場所で保存すること。
• 設定は設定用のリポジトリで管理した値を常に使うこと
• アプリケーションやバージョン、デプロイ環境に応じて個別の
値を提供できること
• 設定オプションには明確な命名規約を用いよう
• 設定情報はモジュール化しておこう
• DRY(don’t
repeat
yourself)原則を用いよう
• 設定情報はシンプルに保とう
• 設定はきちんとテストしよう

18. 2.5 環境を管理する
• 設定情報を管理する上でのアンチパターン
– 環境を手作業で構築し、設定ファイルを変更する
• こういった『職人芸』は生産性を大きく下げる
• 完全に自動化されたプロセスで環境構築出来る必
要がある

19. 2.5.1 環境管理のためのツール
• Puppet
– hIp://puppetlabs.com/
• CfEngine
– hIp://cfengine.com/

20. 2.5.2 変更プロセスを管理する
• 本番環境を変更できる人は限られた人でないといけ
ない
• テスト環境は本番環境と同じように扱わなければな
らない
– 管理、デプロイメント、設定が同じ仕組であればよい

21. 2.6 まとめ
• 構成管理プロセスの徹底には、以下の要件が必須
– 本番システムをバージョン管理ツールからスクラッチで構築すること
ができる
– 正しく動くとわかる以前のバージョンにロールバックできる
– ステージングやテスト環境が本番と同じやり方でセットアップされてい
る

22. 私的まとめ
• 直接関係ないことが混じってるが、要はPuppetとか
使って環境構築を自動化しましょうというお話
• 定期的にtrunkに〜のくだりとかは、後の章でも同じ
話がでてくるので省いていいんじゃ・・・