global<\/a> gem resolves this issue by providing object oriented interface for our config files.<\/p>\n\n\n\nInstallation<\/h2>\n\n\n\n Extremely simple:<\/p>\n\n\n\n
gem install global<\/pre>\n\n\n\nor you can also insert the following line into Gemfile:<\/p>\n\n\n\n
gem 'global'<\/pre>\n\n\n\nConfiguration<\/h2>\n\n\n\n Before using the gem, we need to configure directory that is used as a source to load yaml files and our application environment:<\/p>\n\n\n\n
Global.environment = \"ENV_HERE\"\nGlobal.config_directory = \"PATH_TO_DIRECTORY\"\n<\/pre>\n\n\n\nFor Rails, put initialisation into config\/initializers\/global.rb<\/code>:<\/p>\n\n\n\nGlobal.environment = Rails.env.to_s\nGlobal.config_directory = Rails.root.join('config\/global').to_s\n<\/pre>\n\n\n\nUsage<\/h2>\n\n\n\nGeneral<\/h3>\n\n\n\n Let’s say our application has web and api parts divided by different hostnames. Also, each environment has its own configuration. We place all this stuff to config\/global\/hosts.yml<\/code> file with the following structure:<\/p>\n\n\n\ntest:\n web: localhost\n api: api.localhost\n\ndevelopment:\n web: localhost\n api: api.localhost\n\nproduction:\n web: myhost.com\n api: api.myhost.com\n<\/pre>\n\n\n\nNow, for the development environment we have the following data:<\/p>\n\n\n\n
> Global.hosts\n=> { \"api\" => \"api.localhost\", \"web\" => \"localhost\" }\n> Global.hosts.api\n=> \"api.localhost\"\n<\/pre>\n\n\n\nNamespacing<\/h3>\n\n\n\n If there are different settings groups, we can split the files by directories in order to make configuration more organised. For example, let’s say web should have basic auth.config\/global\/web\/basic_auth.yml<\/code> with:<\/p>\n\n\n\ntest:\n username: user\n password: secret\n\ndevelopment:\n username: user\n password: secret\n\nproduction:\n username: production_user\n password: supersecret\n<\/pre>\n\n\n\nThen in the development environment we will have:<\/p>\n\n\n\n
> Global.web.basic_auth\n=> { \"username\" => \"development_user\", \"password\" => \"secret\" }\n> Global.web.basic_auth.username\n=> \"development_user\"\n<\/pre>\n\n\n\nDefault section<\/h3>\n\n\n\n In our previous examples, development and test sections were quite similar. To DRY our configs, use default<\/code> section:<\/p>\n\n\n\ndefault:\n web: localhost\n api: api.localhost\n\nproduction:\n web: myhost.com\n api: api.myhost.com\n<\/pre>\n\n\n\nData from the default section is used until it’s overridden in a specific environment.<\/p>\n\n\n\n
ERB support<\/h3>\n\n\n\n Global supports erb injection to make configuration dynamic. For this, place the following code into ‘global\/file_name.yml’<\/p>\n\n\n\n
test:\n key: <%=1+1%> \n\ndevelopment:\n key: <%=2+2%>\n\nproduction: \n key: <%=3+3%>\n<\/pre>\n\n\n\nAs a result, here’s what we have in the development environment:<\/p>\n\n\n\n
> Global.file_name.key\n=> 4\n<\/pre>\n\n\n\nReferences<\/h2>\n\n\n\n For more details, check out the source code and documentation on github<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"Quite a lot of applications face the problem of storing configuration data, where configuration differs for development, test and production environments. Yaml files is a common way of organising application settings. They help make our configuration clean, as well as allow loading it somewhere to constant or global variable and then re-use in application. But…<\/p>\n","protected":false},"author":44,"featured_media":5086,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["Olexander Paladiy"],"class_list":["post-5047","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t