I personally am not a fan of config files at all, a lot of this stuff comes down to preferences and experiences, but I have seen the environmental configurations being put in config files problem repeated over and over, then someone checks in the config with the project and someone checks it out and then it gets installed in an environment. It is considered good practice to separate configuration data from the code entirely, so that a commit, with config files, to source code cannot blow up an environment. Many recommend, as is the case with this author, that that separation happen by putting the config in environmental variables, that way it is wholly separated from the application and an updated to the application cannot blow up an environment. I agree with the conclusion and through experience, have found it to be the best solution as well. That beings said, using a tool like Puppet to automate and turn over, the process to infrastructure, is pretty simple, but some groups don't like to use tooling and if not, having an environmental configurations script in a separate repository, is just as valid of a process and will reduce the failure point.
I've arrived at the same conclusion recently, at least as far as keeping production configuration out of config files and putting them in environment variables instead. I'm curious, what is your take on configuration for the development and test environments?
I'd prefer that a project can be set up for development as quickly as possible, so my current approach is to check in default configurations for the development environment that are overridden with environment variables in production.
It depends on the technology that you use but many runtime environments allow the IDE to provide environment like configuration in the project properties, I tend to like to use that approach over specialized config files because the project files are wholly separate from the code base. For example the JVM allow you to send flags to it on initialization, Netbeans and Eclipse provide an interface to manage those flags from a development perspective, to the JVM they look no different than environmental variables and therefore the absence of the project files means that it transparently gets that configuration from the environment. I am a fan of that solution over specialized config files that are developed by the development team.
I personally am not a fan of config files at all, a lot of this stuff comes down to preferences and experiences, but I have seen the environmental configurations being put in config files problem repeated over and over, then someone checks in the config with the project and someone checks it out and then it gets installed in an environment. It is considered good practice to separate configuration data from the code entirely, so that a commit, with config files, to source code cannot blow up an environment. Many recommend, as is the case with this author, that that separation happen by putting the config in environmental variables, that way it is wholly separated from the application and an updated to the application cannot blow up an environment. I agree with the conclusion and through experience, have found it to be the best solution as well. That beings said, using a tool like Puppet to automate and turn over, the process to infrastructure, is pretty simple, but some groups don't like to use tooling and if not, having an environmental configurations script in a separate repository, is just as valid of a process and will reduce the failure point.
I've arrived at the same conclusion recently, at least as far as keeping production configuration out of config files and putting them in environment variables instead. I'm curious, what is your take on configuration for the development and test environments?
I'd prefer that a project can be set up for development as quickly as possible, so my current approach is to check in default configurations for the development environment that are overridden with environment variables in production.
It depends on the technology that you use but many runtime environments allow the IDE to provide environment like configuration in the project properties, I tend to like to use that approach over specialized config files because the project files are wholly separate from the code base. For example the JVM allow you to send flags to it on initialization, Netbeans and Eclipse provide an interface to manage those flags from a development perspective, to the JVM they look no different than environmental variables and therefore the absence of the project files means that it transparently gets that configuration from the environment. I am a fan of that solution over specialized config files that are developed by the development team.
3 replies →