【Jenkins】自動リリースへの旅路(3)～ビルド環境の構築 番外

※この記事でやりたかったこと、作業環境などは(1)の記事を参照下さい
https://note.com/yone3_note/n/nde31d1db29f5

【やったこと③：リリース環境ごとに環境変数を変える】

今回は、番外編ということで
本質的には自動リリースとは外れるんですが・・・

今回の構築環境では、動作を確認できる環境が３つあります。

(1) ローカル(Windows)環境
(2) ステージング環境
(3) 本番環境

この、それぞれの環境でDB接続先やらURL(ホスト名)やらを
変更するにあたって、ソースコードを直接編集しにいくのは
ナンセンスですよね。
(今回の例だと３パターン作る必要ができてしまいます・・・)

本体の動作(ソースコード)はそのままに
例えば、DB接続先だけを変える、みたいなことをするには
どうすればいいんでしょうか。

やり方は色々あります。
１つ例を挙げるなら、Gradleビルド時に処理を分岐させてあげることです。
Gradleは「タスク」という概念がありGroovyという
Javaっぽい構文でビルドスクリプトを作ることができます。
タスク処理で、ローカル・ステージング・本番と
処理を分けてやることもできます。

但し今回に限っては、環境ごとに分けるのが
「application.properties」の設定内容だけで良かったため
(主にDB接続先ですね)
以下のようなビルドの動きにしました。

①：予め、ローカル・ステージング・本番、それぞれの環境用の
application.propertiesファイルを用意し「env」ディレクトリに
入れておく。
※「env」は手動で作っておきます

②：Gradleビルド前に①の「env」から対象の環境用の
application.propertiesをresources配下にコピーする

③：②後、Gradleビルドする(warができる)

④：デプロイする

それぞれについて補足します。

①：予め、ローカル・ステージング・本番、それぞれの環境用の
application.propertiesファイルを用意し「env」ディレクトリに
入れておく。

ローカル環境での開発では全く関係ないものになりますが
予めステージング・本番リリース用に設定を書き換えた
「application.properties」を「env」というディレクトリに
入れておくようにします。

今回の例では
・application-dev.properties(ステージング環境用)
・application-local.properties(ローカル環境用)
・application-prd.properties(本番環境用)
の３つを作りました。
ローカル用は正直要らない気もしてますが
まぁ、一応作ってます(笑)

②：Gradleビルド前に①の「env」から対象の環境用の
application.propertiesをresources配下にコピーする

リリース対象環境ごとにJenkinsジョブでコントロールします。

Jenkinsジョブでは、「ビルド」の項目で
処理に順番を設定することが可能です。
なので、①application.propertiesの差し替え⇒②Gradleビルド
という流れを作ることも可能です。

③：②後、Gradleビルドする(warができる)
④：デプロイする

こちらは以前の記事で書いていますので
そちらを参照してください。

以上です。ここまで読んで頂いてありがとうございます。