Nightwatch.jsをE2Eテストフレームワークとして実プロジェクトに適用する時のtipsまとめ
mmmuser
デロイト トーマツ ウェブサービス株式会社(DWS)公式ブログ
こんにちは。土居です。この度、弊社コーポレートサイトをリニューアルいたしました。
クラウド入門記事や事例紹介などなど、大きく刷新・コンテンツを充実させておりますので是非ご覧ください。
今回、構築はGatsby.js(Reactベースのフレームワーク)を使用したのですが、その際に環境変数の扱いで少しハマってしまったのでご紹介したいと思います。
弊社ではCircleCIによってpush先ブランチごとにデプロイ環境を分けていますが、その際によくdotenvを用いてそれぞれの環境変数を設定しています。
API_URL='dev-api.mmmcorp.co.jp'
API_URL='stg-api.mmmcorp.co.jp'
のように、ビルド時にcross-envでNODE_ENV=stagingといったように渡して、環境ごとに.env.*を使い分けている
Gatsby.jsでは、.envファイルを利用することができるのですが、以下の2種類の使い分けになっています。
ここでNODE_ENVにstagingなどを渡してあげれば、.env.stagingを読んでくれるのかな、と思ったのですが。。
gatsby buildした場合は常にNODE_ENV=productionとなり、環境変数も.env.productionの値が利用されます。
以下のように.env.*にGATSBY_ACTIVE_ENVを利用するよう追記し、
let activeEnv =
process.env.GATSBY_ACTIVE_ENV || process.env.NODE_ENV || "development"
require("dotenv").config({
path: `.env.${activeEnv}`,
})
module.exports = {
siteMetadata: {
...
cross-envを使って"staging"を渡す。
"scripts": {
"build:stg": "cross-env GATSBY_ACTIVE_ENV=staging gatsby build"
...
こうすれば、自由に.env.*を利用することができます。
参考: https://www.gatsbyjs.org/docs/environment-variables/