I’ve been seeing it and hearing about it more and more, and every time I do, I cringe.
“Hey, how do I test out our web app?”
“Oh modify your hosts file so that when you go to wonkywares.com it goes to test.wonkwares.com.”
“Umm… ok, that sounds great.”
What this is doing
What I am talking about is going to C:\windows\system32\drivers\etc\hosts and adding entries to that file that map ip addresses to host names.
The hosts file is basically a mapping for ip addresses to host names.
So if you put an entry,
207.46.0.87 google.com
in the file, when you type google.com into your browser you will go to bing.com instead. (That is the ip address for bing.com.)
Why would someone do this?
Well, if you have some code, automated scripts, or process that uses your real production domain name, you can modify your hosts file so that the production host name gets resolved to the test ip address.
Magically when you go to wonkywares.com you will instead go to test.wonkywares.com.
Yes, I do realize this may seem cool and clever.
Heck, you might have stopped reading this blog and called an emergency meeting so you can tell everyone on your team how they can modify their hosts file to magically make your production scripts work on test without passing in the url.
What could possibly go wrong?
Let me give you a scenario:
“Okay Jeff, I’m gonna run the tests scripts on my new workstation to make sure everything is still working right.
“Joebob, how do those fancy dandy test scripts of yours work again?”
“Well Jeff, they drop all the data in the test database and then create new test data, run the tests, and clean up the data after them again.”
… Joebob runs the test scripts and watches as they all pass, thinking about how awesome and clever he is.
RING… RING… RING…
“Hello, this is Joebob.”
“Hi Joebob, this is the CEO, Mr. Wonky, I am getting reports that there are no products at all being displayed on our production website.”
“Oh shnikies! I must have forgotten to modify my hosts file to point wonkywares.com to test.wonkywares.com. I ran my test scripts against production.”
… Joebob pulls a wonkywares revolver out of his bottom drawer, right next to the single malt scotch he keeps for “planning day.”
I am sure you can guess what happens next.
Let me list for you some of the bad things that can happen if you modify your host file to be clever, instead of parameterizing your scripts or code to be able to take a configurable url.
- You run your test scripts against production because you forgot to configure your hosts file on your new machine.
- You think you modified some production data for a data-fix, but you actually only modified test data.
- Someone else uses your machine and doesn’t know that you have a modified host file.
- You use someone else's machine and forget they don’t have a modified hosts file, so you think you are going to the test website, but you are really modifying live production data.
- Your IT guys switch the IP addresses of the staging and production server as part of a rotation so they can do maintenance work on what was the production hardware. You now are pointing to production instead of staging and have no clue.
- Someone else tries to run your script or code and is not aware that they have to modify their hosts file first. They run your scripts against production.
- You change your hosts file and expect the change to immediately take effect, but your browser is smart and has cached the ip address of the page you just visited.
I am sure you can think of plenty more reasons.
So instead of being “clever” and modifying your hosts file, try making whatever code you are writing take in a parameter for the url to use, or read it from a configuration file.