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 まとめ
• ビルド、デプロイメントプロセスをガイ
ドとして使ってスクリプトを集める
– 自動化は尐しずつ進める
– 何度も繰り返しやって、自動化してく
• スクリプトはデプロイする唯一の方法と
しなければいけない