しょーもない話なんだけどさ、最近JenkinsでちょっとしたCIパイプライン書いてたら、Node.jsとGradleで**「同じ環境変数なのに読み方が全然違う」**って話にぶち当たったんですよ。
Node.js側では process.env.SOMETHING って書くくせに、Gradleだと System.getenv("SOMETHING") じゃないと読めないとか…。
なんでやねん？ って思いながらコーヒー片手に試行錯誤してたら、結局それって言語仕様の違いってだけだったんですよね。
まぁ、結論から言えば「それぞれの言語にはそれぞれの流儀がある」ってだけなんだけど、それでも「CI/CD中毒者あるあるネタ」としては押さえときたい気がしたので、軽くメモっておきます。
本記事で話すこと
- Jenkinsの
environmentブロックで渡した環境変数を Node.js / Gradle 側でどう使うか - 「なぜこんなに書き方が違うのか」の根本原因
- CI/CDの自動化が抱える“設計思想のブラインド”についての雑感
Jenkinsでの環境変数の渡し方
Jenkinsfile でこう書くと、環境変数として下流に渡せます。
parameters {
string(name: 'DEV_DOMAIN_NAME', defaultValue: 'https://api.dev.example.com', description: 'APIのドメイン名')
}
environment {
DEV_DOMAIN_NAME = "${params.DEV_DOMAIN_NAME}"
}
これだけ見れば「よっしゃ、どの言語でもこれで読めるやろ」って思いがちなんだけど……。
ところがどっこい：言語ごとの書き方の違い
Node.js（JavaScript）の場合
export const API_SERVER = process.env.DEV_DOMAIN_NAME;
Gradle（Groovy/Java）の場合
def apiServer = System.getenv("DEV_DOMAIN_NAME")
全然違うじゃん……。
なぜこんなに違うのか？
これは単純に「言語とランタイムの違い」に尽きる。
| 比較項目 | Node.js | Gradle (Groovy/Java) |
|---|---|---|
| 言語 | JavaScript | Groovy / Java |
| 実行環境 | Node.js ランタイム | Java Virtual Machine (JVM) |
| 環境変数の取得 | process.env.VAR_NAME |
System.getenv("VAR_NAME") |
どっちが良い悪いの話ではなく、それぞれの世界で「自然な流儀」が違うってこと。
CI/CDがこの違いを“ブラインド”する
で、こういうのってCI/CDやってると盲点になる。
というのも、CI/CDって**「自動で動けば正義」**みたいな文化が強いから、たとえば process.env と System.getenv の違いが出てきても、
とりあえず通ればいいや
ビルドできたからヨシ！
で済ませちゃうことが多い。
でも、元をたどればJavaScriptとJavaの言語設計の違いなんだよね。
コンテナに突っ込めば全部一緒に見えるし、Jenkinsfileでは全部 env.VAR で扱えるから、**「実際に誰がそれを読むか」**の視点が抜けがちになる。
一言でまとめると：
CI/CDがコード間の橋を架けてくれる分、
その下に流れてる川の深さを忘れがちになる。
おわりに
Jenkinsの environment を介して複数言語に環境変数を渡すのは日常的なことだけど、
そのたびに「これ、どっちの書き方だっけ？」ってなるの、地味に効くよね。
この記事が、同じように env 地獄にハマった誰かの小さな助けになれば幸いです。
ショーもない話だけど、こういうところに“CI/CDの深さ”が出ると思う。