Using subfolders for Sitecore config files
Recently, I’ve been changing the organization method I’m using when architecting builds for my clients. Sitecore supports automatically patching in include files from subfolders of App_Config\Include, which allows for architecting project-specific overrides and environment-specific settings in a much cleaner manner.
Kamruz Jaman just wrote a great post about this on Friday. The upshot? Stop putting your files in the primary Include folder and make sure you use subfolders!
Another few tips to add to the post:
- Use a naming convention for environment files. You want to make sure you have a way for deployment scripts to determine whether a file belongs to your primary or secondary content delivery server, or if it applies to all environments. An example would be PRD.CD1.CustomSettings.config.example for a file you want to deploy to your primary production environment.
- Use .example for files intended for other environments. If you are trying to manage all of your environment-specific files in a single solution, you will need .example extensions on the files. Otherwise, these files will all activate in your local development.
St-Cyr Thoughts 
Thanks for the pingback (you mistakenly wrote my name as Martin Davies though :-p)
Agree on the naming convention, I very rarely use overrides for config now, instead use SlowCheetah since I find it makes the build process easier. Make sure your name your build configurations correctly though, similar to how you have suggested.
So sorry about that! Obviously was too late for me to be writing 🙂 I’ve updated the post to have your name in there correctly.
I agree on using tools like SlowCheetah for release management, but have found that the overrides do offer a quick way into the automated deployment process when organizations have not decided to move further along in their ALM practices.