Your SlideShare is downloading. ×

Continuous delivery 6

719

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
719
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 大崎的 Delivery #6 @ShinyaOzawa
  • 2. 6.1 導入• 目的 • ビルド・デプロイメントツールに共通した原 則の概要や情報、コツや小技、更なる情報へ の参照 • スクリプトによる環境管理 • 11 章「基盤と環境を管理する」で扱う• 使い続けるものだから注意深く設計、保 守しなければいけない• Rails なら、Rake などを使えば動かすのは 簡単
  • 3. 6.2 ビルドツールの概要 (1/2)• 共通 – タスクが正しい順序で実行され、依存してい る各タスクが正確に一度だけ実行される – 依存関係のネットワーク内にあるタスクをす べて実行する • 本質的な性質 – 「実行内容」「依存する別のタスク」• ツールによる相違点 – タスク指向 or プロダクト指向
  • 4. 6.2 ビルドツールの概要 (2/2)• タスク指向 – 依存関係をタスクの集まりとして記述 – たとえば、Ant • 記述したタスク (テスト含) がすべて一度だけ実行• プロダクト指向 – プロダクト (最終形体) から依存関係を記述 – たとえば、make • 修正されたファイルが含まれるプロダクトをビル ド
  • 5. 6.2.1 Make• 強力なプロダクト指向ビルドツール• コンパイル時間削減に寄与• 欠点 – 大規模だと Makefile の管理が大変 – シェルに依存• 今は Scons が好んで使われている – ただ、Autotools を使った make install に当たる処 理などは個別に書く必要がある – Autotools • OS 依存性を吸収してくれるツール郡 (configure 作ると きとか)
  • 6. 6.2.2 Ant• タスク指向のビルドツール• Java の呼び出しが簡単に書ける• 欠点 – XML が難解 – 定型処理を書くのに時間を要する? – antcall が混乱を引き起こす • タスクからタスクを呼び出すタスク – ビルドプロセスの情報が取得できない – Import、macrodef が新人ユーザに理解されない?
  • 7. 6.2.3 NAnt と MSBuild• Java 開発者が NAnt を作成• Microsoft が NAnt の純正マイナー版を提供 – MSBuild になった• 欠点は Ant と一緒
  • 8. 6.2.4 Maven• タスク指向のビルドツール• Convention over configuration の原則 – http://knowledge.sorich.jp/?Java%2FMaven%2FMaven%E 3%81%AE%E7%89%B9%E5%BE%B4 (引用)• 依存を勝手に解消してくれる• Ivy を Ant のタスクに入れれば依存関係の解消は可 能• 欠点 – 規約に従ってないことが困難 – 拡張するのが大変だが、大概はプラグインがある – 依存ライブラリの自動更新 • 13 章「コンポーネントや依存関係を管理する」で詳細
  • 9. 6.2.5 Rake• プロダクト、タスク両指向なビルドツー ル• Ruby でタスク拡張ができる• Ruby 以外でも使える?• 欠点 – クロスプラットフォームではない • JRuby が急速?に人気を獲得してる理由 – RubyGems が必須
  • 10. 6.2.6 Builder• プロダクト指向フレームワーク&インク リメンタルなビルド• Rake でできることはすべてできる• Maven と同じ規約• Ant タスクも使える• Maven より高速• 欠点 – タスク拡張が極めて困難
  • 11. 6.2.7 Psake (酒)• タスク指向ビルドツール• Windows ビルドツール – PowerShell で書かれている• 依存関係は解消してくれる
  • 12. 6.3 ビルドスクリプトとデプロイメ ントスクリプトの原則とプラク ティス• 一般的な原則とプラクティスの紹介• どのテクノロジーでも適用できる
  • 13. 6.3.1 デプロメントパイプラインのステージそれぞれに対してスクリプトを 書け• ドメイン駆動設計で作れ?• 肥大化したら、ステージ毎に分ける (p158) – コミットスクリプト – 受入テストスクリプト – 非機能要件スクリプト• スクリプトはソース同じリポジトリに バージョン管理する
  • 14. 6.3.2 アプリケーションをデプロイするのに適切なテクノロジーを使 え• 疑似本番環境へのデプロイも自動化されてい ることが重要• 一般的なミドルウェアには付属しているツー ルがあるので、それを使用しなければいけな い• デプロイするのは関係者全員 – デプロイツール設計は最初から全員で考える• ツールは、アプリケーションのアップグレー ド、サービス停止、DB の更新などもできな ければいけない
  • 15. 6.3.3 すべての環境にデプロイする のに、同じスクリプトを使え• あらゆる環境にデプロイするのに、同一 のスクリプトを使う (p159)• 外部連携 URI などは設定情報としてスクリ プトと別に管理する – デプロイメントスクリプトから検索できるこ と• 「アプリケーションをローカルで実行で きるようにするために投資しない理由を どう正当化するか?」?
  • 16. 6.3.4 OS のパッケージングツールを 使え• OS のパッケージングテクノロジーを使うことを強く勧める – deb とか RPM• パッケージングを使えば、Puppet、CfEngine、Marimba に簡単 に載せれる• 多層アーキテクチャの場合も、各々でパッケージを作る• バイナリのパッケージングは自動化されていなければならな い• Rails なら RubyGems だが、できるとこは OS の標準的なパッ ケージ管理に従った方がよい• CPAN はプラットフォームの差異を自動で変換する – CPAN 最強 – cpanm もあるし – perlbrew もあるし
  • 17. 6.3.5 デプロメントプロセスが冪等 であることを保証せよ• 冪等 – 何度やっても同じ結果• 正しく動くとわかっているベースラインから開始する? – 適切なミドルウェア、アプリケーションが動作する設定などすべて含 まれなければいけない• 差分デプロイではなく、スクラッチでデプロイしたほうがいい – 例外 1) クラスタシステムの場合、全体を同時デプロイすることに常に 意味があるわけれはない (クラスタとか全く関係なくね?) • p321 「カナリアリリース」 • 炭鉱のカナリア – 例外 2) コンポーネント毎にアプリケーションが分かれてて、本番のコ ンポーネントと組み合わせテストが完了している場合• rsync とか使ってもファイル単位で保証できる• Puppet は設定分析をし、望ましい状態と同期するために必要な変更 だけを行う – 11 章「基盤と環境を管理する」
  • 18. 6.3.6 デプロイメントシステムをイ ンクリメンタルに進化させよ• シンプルでインクリメンタルなステップ の集まり• すべてのステップを完了させなければい けないわけではない• 開発環境から順序立てて、スクリプトを 作っていき、運用担当者に共有したり フィードバック受けたりで、最後は本番 環境にも同じスクリプトでデプロイでき るようにする
  • 19. 6.4 JVM を対象としたアプリケーションのためのプロジェクト構造• Java プロジェクトの標準的なレイアウト説 明
  • 20. 6.4.1 プロジェクトのレイアウト• Maven 標準ディレクトリ構成の紹介• 6.2.4 参照
  • 21. 6.4.2 ソースコードを管理する• ファイルのパッケージ名と同じ名前のディレ クトリにファイルを格納? – あたりまえってか、それ以外でどうやんだ?• 1 ファイル 1 クラス• 命名規則に従う• CheckStyle、FindBugs で上記規約をコミット ステージで強制する• 生成される定義 (!= config)、メタデータは src に含めない – target において、clean で削除できるようにする
  • 22. 6.4.3 テストを管理する• テスト用はすべて test/[language] に置く• 単体テストコードはソースコードと同じ パッケージ階層で作る• その他のテストは、別パッケージに置け るが普通は同じディレクトリに置く – ビルドスクリプトでフィルタリングを行い、 テストを別々に実行できるようにすればいい
  • 23. 6.4.4 ビルドの成果物を管理する• Maven はビルド結果を target に格納する – バージョン管理にコミットしてはいけない• ビルドプロセスは、最終的に JAR、WAR、EAR のかた ちでバイナリを生成する• 別コンポーネント用 (提供ライブラリ) に別の JAR を提 供してもよい – 13 章「コンポーネントや依存関係を管理する」• JAR を複数生成するポイント – アプリケーションのデプロイメントをシンプルにする – ビルドプロセスを効率的にし、依存関係の複雑さを最小化 する• プロジェクトは一定のサイズに抑えれば、保守、管理 がしやすくなる
  • 24. 6.4.5 ライブラリを管理する• 管理するパターンは 2 つ – Maven や Ivy に完全に委譲 – lib ディレクトリを作り、そこにコピーしとく• より洗練されたアプローチ – 組織内でリポジトリを作り、あらゆるプロ ジェクトで必要となるライブラリを格納して おくこと • 13 章「コンポーネントや依存関係を管理する」• Ivy や Maven は本番筐体に置くな – 本番でコンパイルすな!
  • 25. 6.5 デプロイメントスクリプト (1/2)• 原則「テスト環境や本番環境の変更は、必ず自動かされたプロセス を通じて行わなければならない」• デプロメントをスクリプト化するやりかたは 3 つ – システムが単一の筐体で実行されるなら、その筐体でローカルに実施 する必要なものをすべて行うスクリプトを書く – 大抵は別々なので、コンポーネント毎に分ける • データベースアップグレード • アプリケーションサーバにバイナリをデプロイ • アプリケーション依存のサービスをアップグレード – rsync、scp を使ったバイナリをコピーし、ssh を使ってコマンドを実行• リモートデプロイのやり方は 3 つ – 各筐体にログインしてコマンドを実行 – エージェントを使って各リモートで実行 (次ページ) – プラットフォーム毎に適切なパッケージング技術を使って配布? (次 ページ) • これが一番強力
  • 26. 6.5 デプロイメントスクリプト (2/2)• プラットフォーム毎に適切なパッケージング技術を使って配 布 – ControlTier、BMC BladeLogic のようなデプロイメントツール、 Marionette Collective、CfEngine、Puppet のような基盤管理ツール は適切なバージョンがインストールされていることを保証して くれる • 11 章「基盤と環境を管理する」 – アプリケーションデプロメント管理と基盤管理の両方で同じ ツールセットが使える• エージェントモデル& CI の利点 – 作業削減 • チェックインして、CI サーバを使ってリモートデプロイ – CI サーバがプロセス管理を見える化してくれる – CI サーバがリモートアクセスするので、本番にログインしない などのセキュリティが保たれる – エージェントモデルうんぬんじゃなくて、CI サーバの話
  • 27. 6.5.1 デプロイレイヤとテストレ イヤ• 「適正であることがわかっている土台の 上にシステムを構築するよう努力せよ」 – コンパイルできない変更をテストしない – コミットテストに失敗した変更をテストしな い • むしろできなくね?• ソフトウェアをレイヤ状に考える
  • 28. 6.5.2 環境設定をテストする• 各レイヤをテストして、問題が起きたらすぐに失敗さ せる – 問題の明確化• 極めてシンプルなスモークテストを行い、主要なリ ソースがあることを確認する – スモークテストは、度正常な簡易テスト – p378 「基盤やアプリケーションを監視する」• スモークテストの例 – DB からレコード検索 – Web サイトであれば 200 OK – メッセージブローカーにメッセージ送信 – ファイアウォール経由での ping – ラウンドロビンができているか
  • 29. 6.6 コツと裏技• 解決策や戦略の一覧化
  • 30. 6.6.1 常に相対パスを使え• 絶対パスを使わない? – ソフトウェアをレイヤに分けた時に、OS 層まで入っ てなかったっけ?• すべてにおいて相対パスを使えば、すべてが正し い場所に置かれていることが保証できる?• 絶対パスを例外 – ハードコードされたパスに依存する 3rd ライブラリ• アプリケーションもシステムのパッケージング ツールを使って、FHS などの規約を強制する – 標準的じゃない場所へのインストールは、設定シス テムのオプションを使う – 2 章「構成管理」
  • 31. 6.6.2 手作業を根絶せよ• 手作業は絶対ミスるし、個人に頼る部分 が多い• 「同じことを 2 回やることになったと き」は、プロセスの自動化をする
  • 32. 6.6.3 バイナリからバージョン管理へのトレーサビリティを組み込め• バイナリから生成元のバージョンがわか ることは、とても大切 – .NET ではアセンブリにメタデータを組み込め る – JAR もマニフェストファイルにメタデータを 含めることができる• 他のやりかた – 各バイナリの MD5 をリビジョンと一緒に DB に格納する
  • 33. 6.6.4 ビルド時にバイナリをバージョン管理にチェックインするな• バイナリが独自のリビジョン番号を持つので 混乱する• その代わりに、バイナリとレポートを共通の ファイルシステムに置く?• ソースから再生成できなければ、構成管理を 改善する• 一般的なルールとして、ビルド、テスト、デ プロイメントで生成されるものはチェックイ ンしない – CI でビルドをトリガーとしてリビジョンを紐づけ ておく
  • 34. 6.6.5 テストが失敗してもビルドは 続けよ• 続けるという意味は、失敗したことを記 録し、ビルドプロセスの最後で各タスク の失敗をレポートすればよい• 各タスクでビルドプロセスを止めると、 次のタスクの結果が分からない• Nant、Ant では failure-property で制御でき る
  • 35. 6.6.6 統合スモークテストでアプリ ケーションに制約をかけよ• アプリケーションが不正な状態であれば、 停止する – デプロイスクリプトでデプロイするときに、 正しいマシンかどうかをチェックしてもよい• バッチの話があるが、外部連携とかテス ト起動できないようなのはどうすればい いんだ?
  • 36. 6.6.7 .NET のコツと裏技• .NET のプロジェクトファイルには、実際 にビルドするファイルへの参照が含まれ る – ファイル消してもダメなときがある – Windows では「隠しファイルを表示する」機 能を ON にする• 理想はソリューションから消した時に一 緒に消してくれるといいが・・・• bin、obj も悪さするから消したほうがい い? – 「clean solution」コマンドを打てばいい
  • 37. 6.7 まとめ• ビルド、デプロイメントプロセスをガイ ドとして使ってスクリプトを集める – 自動化は尐しずつ進める – 何度も繰り返しやって、自動化してく• スクリプトはデプロイする唯一の方法と しなければいけない

×