Downloaded 17 times
大崎的デリバリー第２章
- 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に〜のくだりとかは、後の章でも同じ 話がでてくるので省いていいんじゃ・・・