I'm trying to create two different environments on Heroku with my RoR application, i will try to explain myself easily:
my machine -> development environment (A)
a free plan Heroku instance -> test environment (B)
subscripted Heroku instance -> production environment (C)
But I can't push to (B), telling to Heroku "hey, load the "test" environment".
Surfing the net i find this: https://devcenter.heroku.com/articles/multiple-environments but I don't understand why in that guide they talked about "staging" environment. I would be happy to use the 3 default ruby on rails environment: development/test/production
Do you have some suggestions?
Thanks and sorry, but I'm new about Ruby on Rails and Heroku :)
Have a nice day.
Because test is a special environment in the Ruby on Rails world, I'd strongly recommend avoiding using test as an environment name.
I've seen QA used (per another SO question about this topic)... But it's still outside of the convention. So, opposed to test, Heroku's standard is staging, but you could use anything you want (like QA) - I'd just avoid test.
Related
I was just checking on how pipelines work in Heroku. I want the staging and production apps to be the same except that they should access different API endpoints.
How could I achieve that?
Heroku encourages getting configuration from the environment:
A single app always runs in multiple environments, including at least on your development machine and in production on Heroku. An open-source app might be deployed to hundreds of different environments.
Although these environments might all run the same code, they usually have environment-specific configurations. For example, an app’s staging and production environments might use different Amazon S3 buckets, meaning they also need different credentials for those buckets.
An app’s environment-specific configuration should be stored in environment variables (not in the app’s source code). This lets you modify each environment’s configuration in isolation, and prevents secure credentials from being stored in version control. Learn more about storing config in the environment.
On a traditional host or when working locally, you often set environment variables in your .bashrc file. On Heroku, you use config vars.
In this instance you might use an environment variable called API_BASE that gets set to the base URL of your staging API on your staging instance and to the base URL of your production API in production.
Exactly how you read those values depends on the technology you're using, but if you look for "environment variables" in your language's documentation you should be able to get started.
I'd like to get the release version of my app in Heroku on PHP. I was hoping it might be available as an environment variable, for example like $_ENV['HEROKU_RELEASE'] might retrieve v23. Is there a way to get ahold of this?
Yes, that is possible, by enabling dyno metadata on your app with the following command:
heroku labs:enable runtime-dyno-metadata -a
Then, Heroku will set a HEROKU_RELEASE_VERSION environment variable on your app (as well as other ones, which are all described in the article linked above).
That variable includes the number of the current release for your app.
I'm new to phoenix and elixier but the framework looks very interesting.
Currently i'm searching for an equivalent of Rails environment helpers.
Rails.env.production?
Rails.env.staging?
is there a similar implementation in phoenix ?
Best Regards
Eric
This function is not a part of the PhoenixFramework. Elixir's Mix supports three types of environment
Mix.env hold the current stage and give a result of :dev, :test, or :prod.
The develop option is used by default. On tests (mix test) the test environment will be automatically used.
This console call MIX_ENV=prod mix compile will compile the files in production environment.
See Introduction to mix for more information.
In addition to what Fabi755 said you may also interact with the different environments through the Application module. There are functions like Application.get_env/2 which can fetch the same configuration based on the environment you are currently in (like let's say have a config for sending SMS to false in dev, but you have it to true in prod).
Ultimately the environments are not from Phoenix but from Elixir and the Mix tool.
I need to remove a few files when in development environment (for example when using Vagrant) but not in production. I want to disable firewalld when in development, but not in production. I would like to disable selinux whenon development, but not on production.
What is the best practice for doing these? I would like to use my puppet scripts both on development environments (with Vagrant) and on production.
It is not a good practice to have scripts specific to an environment. Instead you should have scripts which will behave differently based on environment. Let me show you how; there are two steps you will need to do for this to work:
Define environments
You will have to define environments - I would suggest directory based environments (Because config based environment support will be dropped eventually). How to setup environments is an intimate topic and I suggest you check out the documentation
Use environments in your code
Let's say you have defined environments such as dev, qa, uat, prod etc. You can get the name of current environment by using $environment variable. Your manifests should leverage the environment variable to decide weather a firewall should be enabled/disabled etc. For example:
(Modified based on Felix's comment, thanks #Felix)
include profile::webserver
if $environment != 'dev'
include profile::firewall
In above piece of code if the $environment does not match to "dev" only then the firewall role is applied!
I've set up NewRelic for a rails application on Heroku.
I notice NewRelic is determining the application name from the rails environment definition. This is mediated through the app_name variable in the newrelic.yml configuration file. However, I run the same rails environment on disparate Heroku applications, each being used for different development testing or staging purposes. So we entirely do not want all those applications (although using the same rails environment) to report back to the same NewRelic 'application'. That would provide no value at all in NewRelic - rather, each Heroku application should be its own 'application' in NewRelic, otherwise we just get one useless aggregate for all those applications each running a different source version of our application with different load or test simulations.
What should be the most straightforward and solid way to configure that separation?
Thanks!
P.S. of course for our production environment we do want to have all dynos report back as one NewRelic application. Just not for disparate staging/test environments.
You could make a new environment variable for each of the disparate staging and test environments, and then pull that environment variable into your app_name in your newrelic.yml staging and testing environments.
For example, you could create an environment variable called SPECIFIC_APP and set it to "staging_one" for one of your apps and "staging_two" for another app, by running these commands in the respective apps:
heroku config:set SPECIFIC_APP=staging_one
heroku config:set SPECIFIC_APP=staging_two
Then, you could modify the New Relic app_name for each of those SPECIFIC_APP environments, like so:
staging:
<<: *default_settings
monitor_mode: true
app_name: <%= ENV["NEW_RELIC_APP_NAME"] %> <%= ENV["SPECIFIC_APP"] %>
You could do the same thing for each of your testing apps, appending an additional app-specific environment variable to the "testing" environment at the end of your newrelic.yml.
This way, each application in the staging and testing RAILS_ENV's would be unique according to what the SPECIFIC_APP environment variable for each application is set to.