As Ember CLI docs say: " Ember apps can be built with only three environments: development, production, and testing."
The question I have is:
is it possible to just build an app for another environment taking into account variables and secrets by environment without using ember-cli-deploy add-on ?
I previously used ember-cli-deploy and deployed to AWS S3 from my terminal without problems. The request from DevOps folks is to build the same app and then just transfer dist folder to AWS S3.
Thank you, @alexspeller, for the response. When you say
If you want to build with different config, you can use environment variables to do that
do you mean the one of available environment variables (testing, development and production) to use when executing ember build --environment={testing or development or production}?
I think, there is a typo in your response, config.js shouldnāt it be environment.js?
Another point, is suppose that I have the following setings in environment.js:
This will never work when running ember build --environment=staging because ember-cli does know about staging environment as there are only testing, development and production. Right ?
Technically you can define other environments like staging but itās not recommended as Ember itself only recognizes the three (test, development, production). So what you posted above will probably āworkā, but you have to be very conscious of how ember is treating the build beyond just setting up those five variables. Likely itās defaulting build settings to development which isnāt necessarily what you want. Itās better to do as @alexspeller mentioned and use the three basic environment settings and then set system environment variables and read from those for things that need to be customized.
@dknutsen, OK, got it. Personally, Iād prefer using ember-cli-deploy as it is more flexible and makes it possible to manage the variables by environment in separate files (env.deploy.staging, env.deloy.production, etc.) as well as to have a default ones defined in .env file. Iām not really a big fan of defining all the used variables (api host, secrets, etc.) on a system level.
Thank you guys for your responses !
You can still do that without ember-cli-deploy by using an npm package like dotenv or something. In fact you can probably look at the code that ember-cli-deploy uses to read those files and more or less do the same thing, just do it in your config/environment.js file. Iāve used dotenv lib in the past to do something like this for managing variables in development and production.
@dknutsen yeah, me too before learning e-c-deploy
Nevertheless, even with ember-cli-dotenv, I donāt think it to be possible to build an Ember app for an environment other than one of 3 existing ones in ember-cli. What it does, if Iām not mistaken, it just provides a way to keep variables like figaro gem in Rails world in separate files and keep them away from being committed.
Anyway, the guard clause in environment.js file of an Ember app just checks for one of the 3 possible environments and I canāt see how, for example, it is possible (if it is) to trigger a build for staging with ember build --environment=production and pull the corresponding variables from whatever tool you use. Thatās the question. Iām of course aware that this is not a traditional way to go and thatās why Iām just searching for arguments to avoid doing that
Yeah youād have to do something more like TARGET=staging2 ember build -e production
and then in config/environment.js you could say:
if(process.env.TARGET === 'staging1') {
// staging one setup here
}
if(process.env.TARGET === 'staging2') {
// staging two setup here
}
Obviously you still have to choose which ember environment you want to build also, but think of that more like choosing whether or not you want minification, sourcemaps, fingerprinting, etc. or not, and then your environment variables set up specifics.
Anyway, plenty of ways to go about it, itās just easier to avoid weird build issues if you let ember build how it is meant to and you configure your build targets using environment variables.
Ah, OK, - I didnāt know that we could pass in environment variables like that (looks like a Rails way) by prefixing the main command to be executed. Iāll take a try and see how it goes by always building a production-like build but passing in different variables as you suggested. Thanks a lot !
The --environment argument to ember-cli is ambiguously named. Think of it instead as āmodeā. The only modes are āIām doing developmentā, āIām running testsā, and āIām being served to usersā.
You might have many server environments with different settings, but they are all still āin server modeā, so they all use ember-cliās --environment=production.
I agree that ember-cli-deploy is a good choice for managing the difference between multiple targets.
We had a number of apps set up with a āstagingā environment, but we recently started using the āproductionā environment instead (with a āstagingā target for ember-cli-deploy).
Having 100% consistency between our staging and production environments is critical, as we actually shipped a bug that had to do with how minification ran differently between the environments. We even had minification manually turned on in our config, but thereās a number of addons and code paths that hard code a check for environment === 'production'.
Itās valid for Unix based systems, if youāre running Windows try something like this?
set TARGET=staging2 && ember build -e production
Iām not 100% sure that will work as I donāt have a windows box to test on but if not I think itās pretty close, you basically just want to temporarily set the environment variable before running the command