Sometimes you've got to take a step back from what you know and think. We've been managing hosts files for years. In fact, one of my previous posts discusses how we make sure each user keeps the most up-to-date copy on their PC. That's still required for some things, but when my most recent request came in to assist with local development on the developers machines it gave me pause. This is what I came up with ...
Use DNS. We already have DNS setup for our domain mydomain.local. All of the machines in our environment register themselves there. We also maintain local copies of our public domains with the internal private IPs so we can manage and test the environments even when they're not publicly accessible. One of the things we implemented many years ago were wildcard entries so ...
A host entry for * in the domain mydomain.com would resolve for pickle.mydomain.com, mail.mydomain.com or www.mydomain.com. We also implemented subdomains in the scheme to allow for simple development and testing. A * entry in dev.mydomain.com and test.mydomain.com makes pickle.dev.mydomain.com and www.test.mydomain.com valid ;)
The developers were using their local hosts file to reference pickle.dev.mydomain.com so that the URLs would match data driven lookups. The trouble is they had to maintain a huge hosts file and things can get crossthreaded very easily.
That's when it hit me ... use a wildcard entry in a new subdomain named local and point it to 127.0.0.1 in DNS. Now pickle.local.mydomain.com and www.local.mydomain.com both work from each developers' local workstation. The hosts file entries are greatly reduced and revisions/management of said files has all but been eliminated.
It also makes surfing from the server itself possible which can be priceless in troubleshooting -- or proving to the devs it really is their code having a problem and not the server, network or firewall! ;)
No comments:
Post a Comment