1. Local development: localhost, localhost, localhost, joes-dev-box
2. Development / Integration: tomcatdev-svr1, orcldb0, mq-dev, joes-dev-box
3. Testing / UAT: uat-redhat3, uat-rhas7, messageQ-uat1, security-ldap12-DEV
4. Production: appserver-weblogic-PROD0, orclRAQ-1, mq0, fw0-sec-ldap-bldg6

This of course, necessitates a number of custom configurations for every environment, and depending on your technology, your deployment strategy, and your configuration management , it can quickly and rapidly get either unmanageable, or worse, configuration can be lost, or at least not backed up or documented adequately to enable reconsititution in case of catastrophic failure. What we as developers, often yearn for is a simple scheme like the following:

1. app-server, database, message-queue, ldap-server

Of course, we sometimes try to map those sorts of schema into the chaotic environment listed above. Then we have custom host-file entries to manage the IP address resolution for us. of course, is this /etc/host file in any sort of configuration management scheme? Usually not. The trick is course, to use the schema as above but /etc/resolv.conf file to force resolution to a default sub-domain, which in the four cases above, are;

1. developer
2. integration
3. uat
4. prod

Then using either network-based split-segment DNS resolution, or simply a private dns server only visible to resources inside the firewall, to resolve to the relevant sub-domain and thence to the correct IP. But then, there’s the inertia from the infrastructure management, who want to identify machines according to the operating system and the major software brand that’s installed into them, rather than the functional description. Quite apart from the fact that those two schemes can live side by side anyway in a split-segment DNS.

I’m sorry that I don’t have a full solution, I just wish it was easier.