Ember CLI 环境变量在CircleCI中的加载问题解析

问题背景

在使用Ember CLI 3.28.6构建的项目中，开发者在CircleCI环境中遇到了一个环境变量加载不一致的问题。具体表现为：在config/environment.js文件中正确设置了IS_TEST_ENV标志为true，但在测试辅助文件中导入时却显示为false。

环境变量配置分析

在Ember项目中，config/environment.js是定义环境变量的核心文件。开发者通常会这样配置：

module.exports = function() {
  let ENV = {
    APP: {
      IS_TEST_ENV: false
    }
  };

  if (process.env.TEST_FLAG) {
    ENV.APP.IS_TEST_ENV = true;
  }
  
  return ENV;
};

问题现象

在CircleCI环境中，虽然控制台日志显示ENV.APP.IS_TEST_ENV被正确设置为true，但在测试辅助文件中导入时却变成了false：

import ENV from 'company/config/environment';

console.log(ENV.APP.IS_TEST_ENV); // 输出false，与预期不符

根本原因

经过排查，发现问题出在构建过程中。Ember的构建系统会基于不同的环境（development、test、production）生成不同的环境配置。在CircleCI环境中，测试运行时的环境变量实际上是由构建步骤决定的，而不是直接读取config/environment.js文件。

解决方案

方案一：正确设置构建环境

确保在运行测试时使用正确的构建命令和环境变量：

TEST_FLAG=true ember test

方案二：使用Embroider宏

更现代的解决方案是使用@embroider/macros包提供的条件编译功能：

import { isTesting, macroCondition } from '@embroider/macros';

if (macroCondition(isTesting())) {
  // 仅在测试环境中执行的代码
}

这种方法不仅解决了环境变量问题，还能确保测试代码不会被打包到生产环境中。

最佳实践建议

1. 环境区分：明确区分构建时环境和运行时环境
2. 宏的使用：对于测试专用代码，推荐使用条件宏
3. 构建配置检查：定期检查CI/CD流水线中的构建配置
4. 日志验证：在关键节点添加环境验证日志

总结

在Ember项目中处理环境变量时，需要理解构建系统和运行时环境的差异。特别是在CI/CD环境中，构建步骤可能会覆盖或修改原始的环境配置。采用条件宏或确保正确的构建参数传递，可以有效避免这类问题的发生。