大崎的デリバリー第2章

953 views

Published on

2 Comments
1 Like
Statistics
Notes
  • 第一回の資料はこちら
    http://slideshare.net/chabudaigaeshi/1-13376219
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • 謎の集団『大崎的デリバリー』による継続的デリバリー読書会の第二回の資料です。
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
953
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
17
Comments
2
Likes
1
Embeds 0
No embeds

No notes for slide

大崎的デリバリー第2章

  1. 1. 『継続的デリバリー』読書会   第2章   構成管理 大崎的デリバリー   @kapara_c
  2. 2. 2.1  導入   構成管理の定義 •  プロジェクトに関連するあらゆる成果物とそれ らの間にある関係性が、保存され、検索され、 一意に特定され、修正されるプロセスのこと である。  
  3. 3. 2.1 導入   適切な構成管理とは •  あらゆる環境を再現できる   –  OS   –  パッチレベル   –  ネットワーク構成   –  ソフトウェアスタック   –  デプロイされるアプリケーションとその設定  •  インクリメンタルな変更を行い、他の環境に対して簡 単にデプロイできる  
  4. 4. 2.1 導入   適切な構成管理とは •  変更点を容易に確認できる   また、誰がいつ変更を行ったかを追跡できる  •  コンプライアンスの規約をすべて満たす  •  チームの全員が必要な情報を取得し、変更すること ができる。   –  チーム間に壁を作って、サイクルタイムが長くなり、フィー ドバックが減ることになっていないか?  
  5. 5. 2.2バージョン管理を使う •  バージョン管理システムを使う理由   –  ソフトウェアの特定のバージョンを構成しているものを知り たい   –  いつ、誰が、何のために、何を行ったのかを把握できる   •  チームが離れた場所、別の時間帯で作業しても協力できる
  6. 6. 2.2.1 ひとつ残らずすべてバージョン 管理に保存せよ •  ソースコード  •  テスト、データベーススクリプト  •  ビルド・デプロイメントスクリプト  •  ドキュメント  •  ライブラリ  •  設定ファイル  •  テスト環境や本番環境を再現するのに必要な情報    アプリケーションのバイナリと実行環境を再現するのに必要なすべてを保存する  
  7. 7. 2.2.2 定期的にtrunkにチェックインせよ •  こまめにチェックインすることで、問題の解決を容易にするこ とができる  •  機能毎にブランチを切る方法は、継続的インテグレーションと は相容れない   –  機能の統合が先延ばしになる   –  複数のブランチを作ると問題はより複雑になる   –  統合に関わる問題がマージの時にしか発見されない   –  マージツールも意味上の競合は解決してくれない  •  チェックインの際にビルドを壊さないために   –  チェックインの前にコミットテストを一式実行する   –  変更をインクリメンタルに行う
  8. 8. 2.2.3 意味のあるコミットメッセージを使え •  どんな変更をしたのかをきちんと説明するコミットメッセージ を使うことで、後々何時間というデバッグをしなくて済む  •  よりよいメッセージ   –  1行目に要約を書く   –  以降の複数行にわたって詳細な説明を記述する  •  コミットをプロジェクト管理ツールに紐付ける   –  紐付けができていないコミットが失敗するように  
  9. 9. 2.3 依存関係の管理   2.3.1 外部ライブラリを管理する •  RubyGemsなどを使って特定のライブラリをダウン ロードできるようにする   –  リポジトリが肥大化しなくて済む  •  社内の共通リポジトリに外部ライブラリのコピーをお いておく   –  新メンバーのスタートアップが楽になる  •  どちらにしても、外部ライブラリの正確なバージョン を常に指定しなければならない  
  10. 10. 2.3.2 コンポーネントを管理する •  一つのコンポーネントをビルドした場合に、依存関 係のあるコンポーネントのみリビルドして欲しい  •  しかし、現実にはそんなことができるツールはない  •  ビルドエンジニアが自前で依存関係を管理する必要 がある
  11. 11. 2.4 ソフトウェアを管理する   2.4.1 設定と柔軟性 •  ソースに対する安全装置はいろいろあるが、設定に 対する安全装置はほとんどない  •  設定を柔軟にしようとするせいで分析麻痺に陥る  •  システムが複雑になってしまい、柔軟性の恩恵が失 われてしまう  •  スモークテストは設定によって起こる問題を和らげ てくれる  
  12. 12. 2.4.2 設定の種類 •  設定の種類にはいくつかある   –  ビルド時の設定   –  パッケージング時の設定   –  デプロイメント時の設定   –  起動時や実行時の設定  •  ビルド時やパッケージング時の設定は悪い設定   –  あらゆる環境に同じバイナリをデプロイできるべき  •  設定情報は可能な限り同じ手段で提供されるべき
  13. 13. 2.4.3 アプリケーションの設定を管理する   設定にアクセスする •  ファイルシステム経由の管理   –  あらゆる言語でサポートされる   –  アプレットのようなものでは使えない  •  Web経由で管理  •  設定にアクセスする際は、インターフェイスのみ公開 し、実装は隠蔽すること  
  14. 14. 2.4.3 アプリケーションの設定を管理する   設定をモデリングする •  設定情報はタプルの集合でモデル化される  •  設定情報は以下に依存する   –  アプリケーション   –  アプリケーションのバージョン   –  アプリケーションの実行環境  
  15. 15. 2.4.3 アプリケーションの設定を管理する   システム設定をテストする •  外部サービスへの参照が適切であるかテストする   –  最低でもすべての外部サービスにpingを打つ程度は   –  依存しているサービスが一つでも動いてなければ落ちな ければならない  •  アプリケーションがインストールされた後で、いくつ かスモークテストを行う   –  設定が正しいことに依存するテストをいくつか行う
  16. 16. 2.4.4 アプリケーションをまたいで設定を 管理する •  プロジェクトに関連する設定を一欄できるようにする  •  可能であれば設定を自動生成するように  •  もしくはWikiなどに集約させる  •  動作しているアプリケーションの設定情報を監視シ ステムを通じて見ることができるように
  17. 17. 2.4.5 アプリケーション構成管理の原則 •  設定オプションはソースコードと同じレポジトリで管理する。た だし、値は別の場所で保存すること。  •  設定は設定用のリポジトリで管理した値を常に使うこと  •  アプリケーションやバージョン、デプロイ環境に応じて個別の 値を提供できること  •  設定オプションには明確な命名規約を用いよう  •  設定情報はモジュール化しておこう  •  DRY(don’t  repeat  yourself)原則を用いよう  •  設定情報はシンプルに保とう  •  設定はきちんとテストしよう
  18. 18. 2.5 環境を管理する •  設定情報を管理する上でのアンチパターン   –  環境を手作業で構築し、設定ファイルを変更する  •  こういった『職人芸』は生産性を大きく下げる  •  完全に自動化されたプロセスで環境構築出来る必 要がある
  19. 19. 2.5.1 環境管理のためのツール •  Puppet   –  hIp://puppetlabs.com/  •  CfEngine   –  hIp://cfengine.com/  
  20. 20. 2.5.2 変更プロセスを管理する •  本番環境を変更できる人は限られた人でないといけ ない  •  テスト環境は本番環境と同じように扱わなければな らない   –  管理、デプロイメント、設定が同じ仕組であればよい  
  21. 21. 2.6 まとめ •  構成管理プロセスの徹底には、以下の要件が必須   –  本番システムをバージョン管理ツールからスクラッチで構築すること ができる   –  正しく動くとわかる以前のバージョンにロールバックできる   –  ステージングやテスト環境が本番と同じやり方でセットアップされてい る  
  22. 22. 私的まとめ •  直接関係ないことが混じってるが、要はPuppetとか 使って環境構築を自動化しましょうというお話  •  定期的にtrunkに〜のくだりとかは、後の章でも同じ 話がでてくるので省いていいんじゃ・・・

×