ビルド・デプロイメントスクリプトの概観

1.はじめに

継続的デリバリーにおける、ビルド・デプロイメントスクリプトについての調査記録です。
継続的デリバリーの中での、ビルド・デプロイメントスクリプトについての概観を記載します。
『継続的デリバリー信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』の第6章に対応します。

2.概要・目的

アプリケーションのビルド・テスト・パッケージングのスクリプト化のための最初のステップが、コマンドラインからのビルドの実行である。テストも、有名なフレームワークを使えば比較的簡単に実行できる。これらにより、CIを開始できる。
コンポーネントの増加や、通常と異なるパッケージングの必要から、複雑なビルドスクリプトを作る必要が生じる。さらに、デプロイメントの自動化のためには、より一層複雑になる。
本稿では、これらの複雑なスクリプトを扱うために、ビルド・デプロイメントツールに共通した原則の概要や、必要な情報、テクニック、さらなる参照などを記載する。

3.対応概要

本節では、ビルドスクリプトとデプロイメントスクリプトに関する一般的な原則とプラクティスを紹介する。

(1)ビルドスクリプトの設計

ビルドスクリプトが実装しているプロセスを明確に表現したものであることが理想。
スクリプトを適切な構造にし、きれいに保ち、コンポーネント間の依存関係を最小化する。
プロジェクト開始時点は、デプロイメントパイプラインを実行するためのあらゆる処理をひとつのスクリプトにまとめておく。自動化されていないステップにはダミーのターゲットを入れておく。
スクリプトが十分に長くなったとき、パイプラインのステージごとに別々のスクリプトに分ける。
これにより、コミットスクリプトができる。このスクリプトは、アプリケーションをコンパイルし、パッケージングし、コミットテストスイートを実行し、コードの静的解析を行うために必要なターゲットをすべて含む。
次に必要となるものが機能の受入テストスクリプトとなる。デプロイメントツールを呼び出してアプリケーションを適切な環境にデプロイし、必要なデータをすべて準備し、最後に受入テストを実行する。また、ストレステストやセキュリティテストといった非機能のテストを実行するスクリプトもある。
スクリプトはすべて、ソースコードと同じバージョン管理リポジトリに格納する。

(2)デプロイメントツールの使用

デプロイメントを自動化する際には、汎用スクリプティング言語ではなく適切なツールを使用する。
デプロイスクリプトは、アプリケーションをスクラッチからインストールするときと同様に、アップグレードも実施する必要がある。そのため、デプロイする前に実行中のアプリケーションをシャットダウンする必要がある。また、既存のDBを更新することもゼロから作成することもできる必要がある

(3)すべての環境へのデプロイに同じスクリプトを使う

デプロイメントスクリプトから区別した設定情報を、スクリプトから検索できる仕組みを提供する。

(4)OSのパッケージングツールを使用する

ファイルシステムをまたがって分散するファイル一式のデプロイのためOSのパッケージングツールを使用する。
また、バイナリのパッケージングは自動化する。

(5)デプロイメントプロセスの冪等化

デプロイするたびに、すべてスクラッチからデプロイする必要がある。環境設定を宣言的に指定するツールを使用する。

(6)デプロイメントシステムをインクリメンタルに開発する

デプロイメントシステムはインクリメンタルに開発する。

4.対応詳細

(1)ビルドツールの責務

ビルドツールは、依存関係のネットワークをモデル化するという共通のコアを持つ。
タスク指向のビルドツールは、コンパイラがインクリメンタルビルドのためのロジックを持つC#などの言語のコンパイルに向いている。
プロダクト指向のビルドツールは、インクリメンタルビルド機能を持ち、CやC++のコンパイルに向いている。

(2)ビルドツールの歴史

ビルドツールの歴史を紐解いた結果として、著者の執筆時点では、以下が洗練されたツールとされている。

Buildr
Gradle
Psake

(3)プロジェクト構造

観点は以下の通り。
レイアウト
ソースコード管理
テスト管理
ビルドスクリプトで別々に実行
ビルドの成果物の管理
ターゲットディレクトリからはバージョン管理にコミットしない。
ビルドプロセスで、アプリケーション内のコンポーネントの構成を決める。
ライブラリの管理

(4)デプロイメントスクリプトの実装

独立したプロセスごとにスクリプトが必要。そこからさらに、機能ごとに個別のスクリプトが必要となる。
観点は以下の通り。
リモートマシンへのデプロイ
デプロイメントツールや基盤管理ツールの使用か、またはエージェントモデルのCIサーバにより、ローカルスクリプトをリモート環境で実行する。あるいは、自前のスクリプトでも可能。
デリバリーの核：「各プロセスは前のプロセスの検証を土台とする」
- デプロイメント前の低次レイヤの検証
  (5)ビルド・デプロイメントの振る舞い
  
  観点は以下の通り。
〇相対パス/×絶対パス
成果物はチェックインせず、メタデータでリビジョンと紐づける
バイナリからバージョン管理へのトレーサビリティ
1ビルドに対して1コミットテストスイートを完遂
統合スモークテストでアプリケーションを制限

5.影響・作用

以下の観点でスクリプトの開発を実施することで、ソフトウェアのビルド・テスト・デプロイ・リリースの自動化のための仕組みを構築できる。

デプロイメントパイプラインはイテレーティブかつインクリメンタルに開発する。
スクリプトをバージョン管理し、デプロイメントの唯一の手段とする。

6.おわりに

以上が、継続的デリバリーの中での、ビルド・デプロイメントスクリプトについての概観です。

7.参考文献

『継続的デリバリー信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化』第6章　ビルド・デプロイメントスクリプト

Learning Records

『継続的デリバリー』第6章学習メモ