6

For those who aren't familiar with the term "staging", it consists of privately deploying your code to a production server (or a clone of your server) so you can make sure nothing is going to break when you go live.

I usually stage my code on domain staging.example.com where example.com is my production domain.

The problem I frequently run into is when some of the application logic depends on the domain name, especially if the domain name is hard coded somewhere.

How do you deal with that situation, assuming you staging and production environments are on the same server?

0

4 Answers 4

5

You could add an alias IP (or use the other NIC) and bind IIS or Apache for your staging server virtual host/server to that particular IP address; you could then create a HOSTS file entry for domain.com to resolve to this new aliased (or secondary) IP address on your test machine (or if you want LAN-wide access to staging through domain.com, you'd create an A record in your LAN DNS server).

Of course you won't be able to hit the actual live server because your new A record or HOSTS file entry will resolve to the wrong IP address until commented out or removed.

2
  • Seems like a good solution, but it assumes I have access to an additional IP right? Not a big deal but just making sure I understood properly. Dec 16, 2010 at 23:08
  • 1
    I'm making an assumption that your webserver is on your LAN and is NAT'ed to the outside. If it's in a colo with a static WAN IP assigned to it, then yes, you'd need another static IP address from your colo.
    – gravyface
    Dec 17, 2010 at 15:19
6

I design all applications to pull information from a database. All my work is in java. Extend the java.util.Properties class so everything is pulled from a database, not a file. The only thing that is different from server to server is the JNDI entry for the datasource. All of your logic on what to do is encapsulated in the class that extends the java.util.Properties class.

This makes it easier for moving from DEV -> UAT -> STAGING - > PROD. We have zero code changes, NO DNS mucking, absolutely No Rebuilding WAR files when going from UAT -> STAGING -> PROD.

We you deal with developers that don't all work in the same environment, DNS mucking/Virutal IPS can become difficult to debug.

This also makes life easier as you start to scale when you have a load balanced/clustered environment. Trying to deal with DNS/ Virtual IPS in your application at that point when scaling up is very difficult and adds more moving parts that can break.

1
  • Fixing the code would be best, yes.
    – gravyface
    Dec 17, 2010 at 15:21
2

I always set the staging server to respond on the real domain and then change my local hosts file to point the real domain name to the IP address of the staging server. Of course this only works if you have separate servers, which you should!

There are some utilities for windows to change the hosts file on the fly, on the mac I use Gas Mask. On windows you might need to flush the dns (ipconfig /flushdns) on mac Gas Mask changes it as soon as you click apply.

2
  • That's also what I do for my dev server but I have no guarantee it is setup identically as my production server. Dec 16, 2010 at 21:03
  • Thanks for this hint, which leads me to Hosts File Editor for Windows: github.com/scottlerch/HostsFileEditor
    – John Doe
    Sep 9, 2016 at 0:55
2

You can setup a DNS server with views. In the internal view return the IPs of your staging environment. In order to avoid conflict only configure the test clients to use these DNS servers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .