There are 2 to Environments config on /config/env/
development.js and production.js
You can run production config with: sails lift --prod
development runs by default: sails lift
how to create staging environment config like /config/env/staging.js
and run with: sails lift --staging
The --prod argument is built-in to the Sails CLI; there's no mechanism for adding new arguments to that currently. But you can get the same effect using the NODE_ENV environment variable:
linux & mac:
export NODE_ENV=staging sails lift
windows:
set NODE_ENV=production
It is extremely easy in sails 0.11. Now you can just add subfolder to you config/env directory and sails engine will interpret it as new environment.
In your case you just need to create folder config/env/staging, put there all needed configuration files and start your application with
NODE_ENV=staging sails lift
Migration guide for sails 0.11 you can find in documentation.
Related
I want to migrate the schema of my models. I wanted to try to do so with the "migrate: alter" command in my env file.
The problem seems to be that on default the startup script will run in production mode which automatically uses "migrate: safe".
I´ve tried changing the "migrate" attribute to alter in die production.js file which does not take effect. Also I tried to set the environment variable to development but it will still start in production mode.
If you have simply installed sailsjs globally with npm, you can try cli command,\
sails migrate
to migrate the database. This is confirmed by sailsjs on twitter.
The documentation of sails (http://sailsjs.org/#/documentation/concepts/Deployment) says:
"Configure the 'production' environment so that all of your css/js gets bundled up, and the internal servers are switched into the appropriate environment (requires linker)"
I thought the linker folder is not used anymore in sails v0.10.(sails.js v0.10 create new project --linker not working Gruntfile.js not used):
"Sails v0.10 no longer uses the linker folder--it was just causing confusion."
If these two quotes are not a paradoxon I would love to hear why.
Can somebody explain that step of deployment above ("Configure the 'production' environment..requires linker")?
When I was deploying our Sails JS application, all I had to do was to set the environment variable NODE_ENV as "production":
export NODE_ENV="production"
I was using forever for keeping the server up, using the command:
forever start app.js --prod
The server then starts in production environment. Before starting, it automatically bundles up CSS and JS files into production.css and production.js respectively.
When running ember build --environment staging I get a build error. In config/environment.js I have a condition looking for staging so I can change the baseUrl to our staging services. But when I try and build with the environment set I get the following error:
You must pass a file to 'EmberApp::import'. For directories specify them to the constructor under the 'trees' option.
Is this a problem with ember-cli or do I need to declare my environment in my Brocfile somehow?
Since Ember currently has issues with custom environments, try using shell variables for modifying behaviour inside single Ember production environment.
If you call ember like DEPLOY_ENV=staging ember build --environment=production then you will be able to access DEPLOY_ENV shall variable inside all JS files via process.env.DEPLOY_ENV and modify their behaviour accordingly.
I personally like decoupling deploy environment from application environment, cause it allows to have a staging server which is just like production.
In particular, for test-cases, I want to keep the test database separate so that the test cases don't interfere with development or production databases.
What are some good practices for separating development, test and production environments?
EDIT1: Some context
In Ruby On Rails, there are different configuration files by convention for different environments. So does Play! 2 also support that ?
Or, do I have to cook the configuration files, and then write some glue code that selects the appropriate configuration files ?
At the moment if I run sbt test it uses development database ( configured as "default" in conf/application.conf ). However I would like Play!2 to use a different test database.
EDIT2: On commands that play provides
For Play! 2 framework, I observed this.
$ help play
Welcome to Play 2.2.2!
These commands are available:
-----------------------------
...OUTPUT SKIPPED...
run <port> Run the current application in DEV mode.
test Run Junit tests and/or Specs from the command line
start <port> Start the current application in another JVM in PROD mode.
...OUTPUT SKIPPED...
There are three well defined commands for "test", "development" and "production" instances which are:
test: This runs the test cases. So it should automatically select test configuration.
run <port>: this runs the development instance on the specified port. So this command should automatically select development configuration.
start <port>: this runs the production instance on the specified port. So this should automatically select production configuration.
However, all these commands select the values that are provided in conf/application.conf. I feel there is some gap to be filled here.
Please do correct me if I am wrong.
EDIT3: Best approach is using Global.scala
Described here: How to manage application.conf in several environments with play 2.0?
Good practice is keeping separate instances of the application in separate folders and synching them i.e. via git repo.
When you want to keep single instance you can use alternative configuration file for each environment.
In your application.conf file there is an entry (or entries) for your database, e.g. db.default.url=jdbc:mysql://127.0.0.1:3306/devdb
The conf file can read environment variables using ${?ENV_VAR_NAME} syntax, so change that to something like db.default.url=${?DB_URL} and use environment variables.
A simpler way to get this done and manage your configuration easier is via GlobalSettings. There is a method you can override and that its name is "onLoadConfig". Try check its api at API_LINK
Basically on your conf/ project folder, you'll setup similar to below:
conf/application.conf --> configurations common for all environment
conf/dev/application.conf --> configurations for development environment
conf/test/application.conf --> configurations for testing environment
conf/prod/application.conf --> configurations for production environment
So with this, your application knows which configuration to run for your specific environment mode. For a code snippet of my implementation on onLoadConfig try check my article at my blog post
I hope this is helpful.
I have database migrations (with sqlalchemy-migrate) working well in my dev environment. However, I'm a little stumped about how to integrate this into my deployment process.
I'd like to use fabric to execute the manage.py file on the remote server but I'm not sure what to use for the repository value in this file. Referring to both 'appname/migrations' and '/usr/local/pylons/appname/env/lib/python2.6/site-packages/appname-05.egg/appname/migrations/'
both fail with a migrate.versioning.exceptions.InvalidRepositoryError
Does anyone have a fabfile and manage.py that plays nicely with sqlalchemy-migrate?
What I did was to generate a manage.py file per the sqlalchemy-migrations docs. In there I hacked it up to load our config information which includes the db auth info. In our case it's a Pylons app so it reads the proper Pylons config.ini file.
http://readthedocs.org/docs/sqlalchemy-migrate/en/latest/versioning.html#project-management-script
Then the fabric commands all interact with the manage.py file vs using the Python API directly. Since everything, from the SA-Migrate manage.py through the app itself I don't run into any sort of path issues like you mention.
Not sure this is a 'exact' fix but maybe helps.