Comment by kls
15 years ago
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.
Two questions. 1) Do you do that for everything? Including database and memcached connection settings, cache settings, basically everything that's configurable about a web app? I'm not an IDE user nor familiar with Java, so that's a serious question. 2) How do new developer's get an environment set up quickly?
1) yep, everything, the code can hit an environment and run based on that environment. No configuration is provided with the code. That being said how you implement it can be pretty flexible you could separate them all out into separate variables or just have one variable with an XML string as the value and parse that string to get configuration, the point is to have the configuration injected into the application by the environment. The details of what those variables look like is the prerogative of the development team.
2) there are several options, a developer (gold CD) virtual is one, where a virtual is set up and configured based on updated configuration and an automated script, or having a environmental script that sets up the development variables on the developers workstation (just make sure it stored in version control independent of the code). Each works well, it just depends on preference, there are a lot of ways one can set it up to work in their environment, just try a few and see which one best fits your development culture.
Thanks. I'm definitely on board with #1. I'm still trying to figure out what will work best for me for #2. It's interesting (and useful) to hear how others solve it.