How do I set up a test domain, to test a site's new perl programs without crashing the live site?


I'm working on a site that will be launched in about a month.  It will use Apache server, running many perl programs that create dynamic HTML.  I use my server on the server farm for development, rather than testing things on a local computer, because it takes just two seconds to upload a new script, and even to restart Apache if necessary.  Also:
  the server is unix,
  I work locally a windows box,
  the server is using MySQL to run the site,
  I don't want to install and debug an installation of MySQL on my windows machine,
  and keep the databases synchronized,
  and this way I can test the pages that require SSL,
and ... a million reasons it works better for me to develop on the real server.

Here's the problem: my code has bugs.  I find them and fix them as I develop.  However, once the site is launched, I don't know how I will test new code, new features, without crashing the live site for people who are actually using it.

Knowing that this problem would rear its head eventually, in my code, I have only *one* place where the site's domain name and path to the unix directory are hard-coded:

sub GetDomainInfo {
      return ("", "/home/www/mydomain");

Then, whereever the domain name or server path is required in the code, I can call GetDomainInfo().

My plan was to have *two* domains, running on the same server.  The other domain would be, and it would contain copies of the identical perl and html files as the real domain, except the other domain's GetDomainInfo subroutine would return
("", "/home/www/mydomaintest")

It didn't work, as I learned from browsing around, because module names clashed.  

I found this link:

...which discusses ways of doing what I want.  I tried using "PerlOptions +Parent", as discussed on the link, but I was never sure where to put it.  And I still had trouble, because most of my URL's get Rewritten, and in the VirtualHost MyDomainTest, Rewrite would prepend httpd.conf's document_root (the-path-to-mydomain, *not* the-path-to-mydomaintest) to the rewritten URL, so when I tried to access, I would get bounced back to

The person who posted on the link above seems to have solved his problem with this:
Use a separate Apache. This isn't as hard as it
sounds. And if you already have a proxy in front
(which you should) it's even easier. Just have some
mod_redirect rules which send requests for your
dev version to a different port and have your other dev
apache listening on that port. You don't
even need another machine.

... but I couldn't find instructions on accomplishing that.

I hope I have adequately described what I'm trying to accomplish.  I'm seeking advice on the best way to set up a testing domain, using code that is identical (or nearly-identical) to the live site, where I can test changes and crash scripts and not interfere with the live site.  I'd like to do it on the same machine, so I have the same access to MySQL.  It seems that I'm getting close with some of the ideas described above, but I need someone who has done this to direct me to a path that would work best and most simply.

Thanks for any help
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

You could create a new VirtualHost.  You would still have just one apache running, but this VirtualHost would have it's own home directory.

If you have multiple domains, it can listen from a different domain. If you have just one domain, you can have it listen on a different port.  Something like this:
Listen 8000
NameVirtualHost *:8000
<VirtualHost *:8000>
	DocumentRoot /home/www/mydomaintest
	<Directory />
		Options FollowSymLinks
		AllowOverride None
	<Directory /home/www/mydomaintest>
		Options ExecCGI Indexes FollowSymLinks MultiViews
		AllowOverride None
		Order allow,deny
		allow from all
	AddHandler cgi-script .pl
	#Whatever other options you want for this...

Open in new window


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Dont even think about testing it on the live domain.  That is just madness.  It is called testing in production and is one of the evil sins.

Set up a new domain.  You can do it as above although thats really not the best thing in the world as it is still on the same production server.  If you really do not have a seperate box or one you can remove from the pool for tests then go this way.  (But it is not very good).  Best thing would be to put it on a seperate box.

You can call the new domain a slightly different name.
If the main site is called then you could set up
The GetDomainInfo code is not needed.  Every language has code to read off the site name from the request.  This would be far better than having to edit it yourself.
You can set up a self sign SSL cert on this domain if you really want to test it like that but if you are not passing real credit card data then you could just enable port 80 and go in with no SSL.
If you do need SSL then either set up your own free cert or use the existing one and add an exception to your browser (or just ignore the errors) when it says 'wrong name'.
You could also use the real cert and set up an entry in your hosts file so you go to the fake site instead.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Scripting Languages

From novice to tech pro — start learning today.