開発プロジェクトでは、よく以下のようなライフサイクルが回ってる。
- テストの実装
- プログラムコードの実装
- テストの実行
- テストが通ったらコードをリポジトリにPush
- 定期的にCIサーバがリポジトリをチェックし変更があったらCIサーバ上でテスト実行
- テストが通った状態のアプリケーションを検証環境へリリース
- 検証環境でのテストが通ったら、本番環境へリリース
※実際は５～７の間にDBのバックアップやマイグレーションとかいろんなタスクが結構ある。
このうち実際に人がやらないといけない作業は大体１～４ぐらいで、５～７については人が作業する必要はなく、自動化できる対象作業。同じ作業といっても手順が複雑であればミスをする可能性もあるし、人がする必要が無い作業を何度も人がするのはムダだ！ということで、今回はJenkinsを使って５～６の作業を自動化してみた。
必要なプラグイン
以下のJenkinsのプラグインが必要なのでインストールしておく。
- Build Pipeline Plugin
ジョブをつなげてビルドパイプラインを形成し、そのパイプラインのビューを提供するPlugin。ジョブがどういう順序で実行されて、どんな状態にあるか可視化してくれる。 - Copy Artifact Plugin
成果物をコピーするPlugin。５のテストに成功した際の成果物を６の検証環境へリリースするジョブに渡すために使用する。
テストのジョブを作成
まずは、５のテストのジョブを作成する。テストの設定は使ってる言語やフレームワーク等によって様々なので割愛。ここでのポイントは以下の２つ。
- 成果物を保存する
リリース用のジョブにテストした成果物を渡すため「ビルド後の処理の追加」から「成果物を保存」を選択する。保存するファイルを入力するフィールドが現れるので、成果物のファイルのパスを指定する。（パスはジョブのワークスペースからの相対パスでOK。例：target/sample.war） - 下流（今回はリリース用のジョブ）ジョブの指定
テストが通ったあとに実行するジョブを指定する。「ビルド後の処理の追加」から「Build other projects (manual step)」を選択し、リリース用のジョブ名を設定する。（「他のプロジェクトをビルド」を追加して下流ジョブを指定することもできるけど、それだとこのジョブが終わると自動的に下流ジョブが実行される。今回はそのまま自動実行ではなく、テストを通った任意のバージョンを選択した上でデプロイをしたかったのでBuild other projects (manual step)を選択）
検証環境へのリリース用のジョブを作成
続いてリリース用のジョブを作成する。このジョブではデプロイ用のビルド処理を定義する。このジョブでのポイントは、
- ビルドトリガー
ビルドパイプラインのViewからのクリックをトリガーとするので、このジョブでのビルドトリガーは設定しない。 - 成果物のコピー
「ビルド手順の追加」から「他のプロジェクトから成果物をコピー」を選択する。プロジェクト入力欄にコピーする成果物のジョブを指定し、コピーする成果物を設定する。
- ビルド（デプロイ）
デプロイ用のコマンドはシェルなりcapistranoなりで用意したものを設定し、↑の成果物をデプロイ対象とする。
ビルドパイプラインのViewを追加
Jenkinsのダッシュボードから＋ボタンで新規ビューを作成する。このとき「Build Pipeline View」を選択する。
続いて、Build Pipeline Viewの設定。「Select Initial Job」でトリガーとなる最初のジョブを選択する。今回は５のテストのジョブを選択。
以上の設定で↓のようなBuild Pipeline Viewができる。（これは何回か動作してるもの）
各ジョブの状態は、
- 緑色 ＝ 成功したジョブ
- 赤色 ＝ エラーとなったジョブ
- 水色 ＝ 未実行のジョブ
今回はリリース用のジョブのトリガーは設定していないので、↑の水色のジョブの右下のリンクが、そのジョブの実行トリガーになってる。
こういった環境があればテストが完了したビルドから検証環境へリリースしたいビルドのリリースジョブのトリガーをクリックするだけでお手軽にリリース作業が可能になる。
実際にビルドパイプラインでジョブのフローが可視化されると、今までわりと大きめな粒度で作成していたジョブを細分化したくなる。
