Do not confuse environment for deploy target

Do not confuse environment for deploy target

Here's a quick note for something I have stumbled upon lately. It's written with EmberJS in mind, but the general concept is applicable to any frontend and backend framework.

Most frameworks have a concept of environment. Many developers are misusing it as a deploy target.

Environment defines whether to enable code minification, asset fingerprinting, test setup, etc.

Deploy target defines a set of endpoint URLs, Content Security Policy hosts, API keys, etc.

Unless you're doing something very simple like a GitHub Pages demo, you should not infer deploy target from environment.

Setting environment and deploy target separately lets you, for example, try a production build against a local server, or a local development build against a production server, so that you're able to use debugging capabilities of a development build on production.

You can configure your Ember app to accept both environment and deploy target CLI parameters:

DEPLOY_TARGET=local ember serve --environment=production

or simply

DEPLOY_TARGET=local ember s -prod

To do that, install the ember-cli-dotenv addon and create several dotenv files, one per environment (including localhost). Dotenv files should contain key-value pairs of different parameters for config/environment.js.

In you app's ember-cli-build.js, have ember-cli-dotenv read the dotenv file that corresponds to the DEPLOY_TARGET env var:

// Assuming modern NodeJS
const dotEnvFileName = (() => {  
  const environment   = process.env.EMBER_ENV || 'development';
  const targetDefault = environment === 'production' ? 'prod' : 'localhost-4200';

  // Provide you most common deploy target here, 
  // so that you can omit the `DEPLOY_TARGET` env var.
  const target     = process.env.DEPLOY_TARGET || defaultTarget;
  const dotEnvFile = `./.env-${deployTarget}`; // Use your naming scheme

  if (!fs.existsSync(dotEnvFile)) {
    throw new Error(`dot-env file not found: ${dotEnvFile} for DEPLOY_TARGET ${target}`);
  }

  return dotEnvFile;
})();

module.exports = function (defaults) {  
  const app =
    new EmberApp(defaults, {

      dotEnv: {
        clientAllowedKeys: [/*key names from env file */],
        path: dotEnvFile
      },

// ...

Now you can use the parameters from dotenv files in your app's config/environment.js:

{
  someApiKey: process.env.SOME_API_KEY
}

Don't forget to gitignore your dotenv files. This way, private API keys will not make it into your code repo, which is good for security.

Seamless software development.

Code management and collaboration platform with Git, Subversion, and Mercurial.

Sign up for free
comments powered by Disqus