For instance, if the site title is the same in development as test and production then you can define it as follows:

development:
site_title: &title My new website

test:
site_title: *title

production
site_title: *title

Thanks for the post and hope this is helpful :)

That’s a really good question. When it comes to whether or not you would add config.yml to your .gitignore personally I feel it just depends. It depends of course first on what the material is you are using in your configuration and secondly it depends on if you repository is public or private. If you do leave it out I would suggest creating a config.sample.yml with test data in it so other contributors on the project can understand the structure of the file. When it comes to deployment I would say that if you are running a public project where the file does not exist I would likely consider looking for a way to create the file within my deployment script. A good example of that would be EngineYard’s chef recipe for creating the database.yml file.

I have a few questions if you don’t mind to clear some things up.

First off, do you include config.yml in your .gitignore file so that it is private and not tracked and when pushing to a remote repo on github? (for private things like API or s3 keys)

And if you do add config.yml to your gitignore file. When pushing up to a cloud server such as heroku, how does heroku have contact with your config.yml file if it’s not on github.

Thanks again for the helpful post!

Glad you liked it! I hope it is helpful for you. The code is run as an initializer so it runs on application initialization storing the information into a constant. While it might run with each request in development mode (can’t recall) it should only run on initialization during production mode.

Question, the file will only be read once right, when the app starts? (as opposed to every request)

So you can do something like…

AppConfig.site_title

Not sure how it works with your nested Yaml config file though.