I am trying to set up my first Cloudbees app.
Is there documentation or tutorial that shows how to
a) set variables depending on the environment. e.g. restful end point URLs have to change depending on dev, test or prod
b) initialize the database. We want to initialise the database when we do from dev to test, but not from test to prod.
Thanks
a) you should use application parameters for your DEV/TEST/PROD application to have adequate URL set as system property. parameters are tied to an application ID, so a common pattern is to deploy same binary to myapp-dev, myapp-test, myapp-prod, but change the configuration bindings.
b) use a boolean system property to disable the database migration process on production.
Related
I want to set spring active profile in weblogic settings.
I have three properties in src/main/resources. For examp : application-dev.properties , application-qa.properties , application-test.properties.
I dont want to keep spring.profiles.active property in my application.properties file. As I have to change it every time whenever I want to deploy in different server.
I want to active the profile in weblogic (my deploying server for application). Whats is the way and how to fetch the value in springboot application?
Thanks
Pass the profile as java argument -Dspring.profiles.active=dev
A secure way to set profiles in springboot applications is to set environment variables with it. In general, it is a good approach, so you can define it differently for each one of your environments (dev, qa and prod).
Please check this discussion, which explains specifically about Weblogic. In java, you need the SPRING_PROFILES_ACTIVE environment variable set.
I have a page with a text field and button. After I fill out text field and press a button my controller is connecting to an API and getting some data based on the text.
I prepared a FAKE_API for testing. Both REAL_API and FAKE_API are in the service container. The FAKE_API is being prioritized when the environment is set to test (.env.test file). The controller gets the API object via dependency injection (constructor argument).
When I am testing using PhpBrowser from Codeception, the environment of the test itself is set to test - this can be checked by var_dump($_ENV['APP_ENV']) from the test.
However, (and this is the issue), if I add var_dump($_ENV['APP_ENV']) to the controller code and run the same test, I can see that the controller actually uses the regular 'dev' environment (set in .env file). This means that the REAL API is being used instead of my FAKE_API.
How can I force PhpBrowser tests to use my .env.test? Is it even possible?
You can't do that.
PhpBrowser communicates to system under test via HTTP, so it can't set environment variables of the system.
Your options are:
Deploy API in test configuration
Pass environment using GET or POST parameters or headers and make your app code accept it. (this is a bad idea)
I want to set Tomcat environment variable as PROD. I tried by putting
set "ENVIRONMENT=PROD"
set JAVA_OPTS="-Dtomcat.runtime.environment.version=PROD"
in catalina.bat
and tried to retrieve it with
env = System.getProperty("tomcat.runtime.environment.version");
but every time env is null! Where exactly does the variable have to be declared in catalina.bat and what's the perfect syntax to set the environment variable? Other possible ways to declare variables are also welcome!
Since you are on Windows and in production, I'm going to assume that you are using a Microsoft Windows Service for Tomcat. If that's the case, the .bat files are completely ignored when launching and stopping Tomcat. There is a service binary that reads the configuration from the Windows Registry and no disk-based scripts are used at all.
If you run the program called tomcatXw.exe (where X is your Tomcat major version number), that will run the configuration GUI. From there, you can configure everything stored in the Registry.
Go to the "System Properties" tab and add your system property -Dtomcat.runtime.environment.version=PROD to the list of properties already found in there. Restart your service and you should be able to see the new system property available to your application (actually the whole JVM, of course).
How can I determine the run mode (Development, Testing, Staging, Production) in a Yesod application?
I have a service that should return a value only in Development and Testing modes. The value is a secret token that will be sent as part of a validation for a newly registered user.
In Development and Testing modes I need to verify that the token sent is the same as the token generated.
In a previous version of Yesod (1.2, I believe), I used the following code, but it no longer compiles:
case appEnv $ settings $ getYesod of
Development -> -- value to return in Development
Testing -> -- value to return in Testing
_ -> -- value to return in Staging and Production
In the newest versions of the scaffolding, we no longer have the concept of environments. Command line arguments can be used to switch which config files we read from, but that's it. If you'd like access to that information, you could use getArgs.
So I'm writing a Facebook App using Rails, and hosted on Heroku.
On Heroku, you deploy by pushing your repo to the server.
When I do this, I'd like it to automatically change a few dev settings (facebook secret, for example) to production settings.
What's the best way to do this? Git hook?
There are a couple of common practices to handle this situation if you don't want to use Git hooks or other methods to modify the actual code upon deploy.
Environment Based Configuration
If you don't mind having the production values your configuration settings in your repository, you can make them environment based. I sometimes use something like this:
# config/application.yml
default:
facebook:
app_id: app_id_for_dev_and_test
app_secret: app_secret_for_dev_and_test
api_key: api_key_for_dev_and_test
production:
facebook:
app_id: app_id_for_production
app_secret: app_secret_for_production
api_key: api_key_for_production
# config/initializers/app_config.rb
require 'yaml'
yaml_data = YAML::load(ERB.new(IO.read(File.join(Rails.root, 'config', 'application.yml'))).result)
config = yaml_data["default"]
begin
config.merge! yaml_data[Rails.env]
rescue TypeError
# nothing specified for this environment; do nothing
end
APP_CONFIG = HashWithIndifferentAccess.new(config)
Now you can access the data via, for instance, APP_CONFIG[:facebook][:app_id], and the value will automatically be different based on which environment the application was booted in.
Environment Variables Based Configuration
Another option is to specify production data via environment variables. Heroku allows you to do this via config vars.
Set up your code to use a value based on the environment (maybe with optional defaults):
facebook_app_id = ENV['FB_APP_ID'] || 'some default value'
Create the production config var on Heroku by typing on a console:
heroku config:add FB_APP_ID=the_fb_app_id_to_use
Now ENV['FB_APP_ID'] is the_fb_app_id_to_use on production (Heroku), and 'some default value' in development and test.
The Heroku documentation linked above has some more detailed information on this strategy.
You can explore the idea of a content filter, based on a 'smudge' script executed automatically on checkout.
You would declare:
some (versioned) template files
some value files
a (versioned) smudge script able to recognize its execution environment and generate the necessary (non-versioned) final files from the value files or (for more sensitive information) from other sources external to the Git repo.