しょーもない話なんだけどさ、最近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の深さ”が出ると思う。