Ember-cli-deploy, different build targets


#1

Hi there,

I am using ember-cli-deploy to make my life easier. Building, uploading via rsync and yelling to a Slack channel works for both my staging & my production build.

Now I need to do something more complex. I must deploy a slightly modified version of my production build (lets call it ‘production2’) to another webserver.

So I added another deployTarget (‘production2’) to deploy.js and copied the production environment to ‘production2’ in environment.js. So issuing 'ember deploy production2 builds the ‘production2’ target and uploads it to my different webserver. Works great & fairly easy.

Now imagine that my ‘production2’ build needs to refer to a different logo in its CSS file… Or may have a different title tag in its head… How could I achieve that?

Regards, Martin


#2

Since this is something related to how the app is built, you’ll probably want to handle that in your ember-cli-build.js file.

Assuming you have this at the top:

var EmberApp = require('ember-cli/lib/broccoli/ember-app');

…then somewhere in your build configuration, you could add:

if (EmberApp.env() === 'production2') {
  app.import('some/other/styles.css');
}

That stylesheet would get pulled into the CSS build only when the environment is production2.

That being said, I think it’s frowned upon to use non-standard environments. Addons (mirage, for example) will make decisions on what to do based on the current environment. If it’s an unexpected environment, I’m not sure there’s a clear strategy for how to handle that.

So, an alternative might be to use environment variables when making decisions in your build. (Ember-cli-deploy uses dotenv, so might be worth working through that re environment variables). But, if you wanted to have a PROD_ENV variable just when doing the deploy, you could do:

if (process.env.PROD_ENV === 'envNumbah2') {
  app.import('some/other/styles.css');
}

And when building:

env PROD_ENV=envNumbah2 ember deploy production

We’ve done something similar to this for building our config/environment.js file. Seems to be working well so far.

I’m certainly curious if anyone has any other strategies for this too!


Abstracting routes away
#3

Thank you for pointing that out. Meanwhile I followed my path and set something like ENV.foo = ‘production2’ to tag the build target accordingly. Then I wrote a component, acessing the ENV.foo to use CSS classes conditionally.

Did not know about that implication with mirage but must admit that my way felt a little hacky right from the start.

Will turn it back to your suggested way, having just ‘development’, ‘production’ and ‘test’ but different deployment lanes with customized env.

Thanks again, Martin


#4

It’s worth noting that you could do the same (importing ENV variables) in your config/environment.js to set an environment value that you can import into your component files, like you’ve already done. That way you don’t have to have a completely different build for the different targets.


#5

Thank you, I revised my configuration and it works well and looks sane again. :slight_smile: