Creating Test and Production Sites with Only One IIS Server

I need to start this off with a 'do not try this at home kids' type of anecdote. I had just come into a brand new job, and had one high priority project handed me with an unrealistic deadline, and one new server. Without hesitation I jumped into the project, worked like a madman, not looking away from my monitor for 6 weeks, at which point I had a 'Version 1.0' ready for release. Now I use the word release quite reluctantly, because there really wasn't anywhere the application would really be released to or from! I had built the system on the production server!

Now hopefully I haven't lost every shred of credibility and respect that you might have had for me. You see, it was beyond my control, and with a tight deadline, I didn't have time to protest. But don't worry, the whole point of this article is to show you how I remedied the situation. And whoever is responsible for the purchasing of servers will be happy to know that the resolution to this problem doesn't call for additional hardware.

If anyone reading this article is wondering what the big deal is, basically it's essential to the success of an application to be able to isolate changes in code from the production environment, until they are tried, tested, true, and ready for deployment. There's nothing quite like that sinking feeling you get in your stomach when there's a serious bug that you know is affecting the end user's ability to accomplish their task (and the reason you know is because they are kind enough to enlighten you to their frustration in not-so-enlightening terms). So it is in the best interests of everyone involved, to have the live (production) code separated from the development (test) code.

Overview, Step 1

Overview

OK, so here's an overview of the situation. I had one server, running Windows 2000 Server, running IIS 5.0 with the .NET framework installed. The application was written primarily in ASP, with a small amount of ASP.Net tossed in the mix. The database was MySQL. I determined that to have a true test environment separated from the production, I would need the following:

A complete copy of the application, including scripts, images, and security settings.

A completely separate but identically structured database.

The ability to connect to the application by the same means (web-browser, optional NT Authentication), but perhaps through a slightly different address.

Control over the code with some sort of versioning system. (optional, but a best-practice nonetheless)

I remembered that a single instance of IIS 5.0 installed on Windows 2000 Server – but not workstation – was capable of running multiple web sites concurrently. After discussing the options with a the network administrators, we determined that best route would be to run the second application, a.k.a. The Test Server, on another port. This was chosen as the best for several reasons: ease of setup, ease of administration, and the URL would be the same, just with a port number attached to the end. Has your appetite been whetted yet?

Step 1: Copy the FilesThis was probably the simplest of all the tasks. It involves two parts:

• deciding on the name of the copied directory
• copying the files

As wwwroot is more or less the standard for an applications root directory, I thought that wwwtest or wwwstage are some appropriate names. It's really not that critical though, so listen to your heart when choosing a name. Wow, now that's cheesy.

Anyhow, the second part of this step is as complicated as the first. Just copy all the files to the new directory. You don't have to worry about installing components or anything, because it's the same server, any components you have installed will work in both applications! Probably the only problem you could encounter here is if you're working on a file while trying to copy it. Make sure all IDEs and graphic editors are closed down, or at least make sure they don't have a hold on any of the files. There, that was simple. Now, on two step 2.

Step 2: It Looks Like the Database, and Smells Like the Database

Once again, there are two parts to this step. So now you're thinking “hey, if there are two parts to this step, and same with the last, and who knows how many parts for the next steps, it's really not a 4-step process!” Yes, you're right, I apologize. I wasn't trying to trick you! But hey, if it was really only 4 steps, there would probably be no need for a tutorial, right?

Now that we've gotten that little discrepancy settled, let's discuss the first part: copying the database.

As I mentioned, I was using MySQL, and MySQL has a wonderful little tool called mysqldump. With this tool, you can easily create a 'dump' of the database, either of the structure only, or even the structure and all content with it. The 'dump' file is a text files filled with SQL commands that would recreate the structure [and optionally the content]. This is normally a .sql file. Once we have the .sql file, we can feed that back into MySQL, into a second – or 'test' – database.

So here's how I did this. First, I created a second, empty database called dbTest. I then made sure the SQLuser (used in the application) user had the same permissions on this database. Then I opened up my command prompt, and typed the following:

cd C:mysqlbin (your install dir here)

mysqldump --quick --user=root --password=******* dbProd > c:bkp.sql

This creates dump file. Now we feed it back into the test database:

mysql --user=root --pass=******* dbTest < c:bkp.sql

There you go. Depending on the size of the database, this shouldn't take too long. One quick caveat. If you are using InnoDB tables, and have foreign keys set throughout the tables, you will need one intermediate step before feeding the .sql file back in. You need to open the .sql file (in notepad or something similar) and enter the following on the first line:

SET FOREIGN_KEY_CHECKS=0;

This will prevent the error that MySQL would produce when it's trying to check the foreign key constraints against records that haven't yet been created.

Now that was the first part. If you've designed your application properly, and no doubt you have, the second step will be extremely easy. You just need to change the connection settings in your test code to point to the test database instead. Hopefully you have the connection settings in either a global.asa (ASP v3.0) file, or in the web.config (ASP.Net) file. You can just make the change to point to the dbTest server instead. If you are using DSN, you will need to create a new DSN entry for the test database, and point your test code to that.

Step 3: Configuring IIS

Wow, I can hardly believe we're already on step 3. It just seems like minutes ago we were on step 2 [nostalgic sigh]. Alright then, let's move on!

The first thing you're going to have to do is open the IIS console. I realize that you want to slap me for stating something so blatantly obvious, but I'm just trying to be thorough.

Once loaded, you can right-click on Web Sites and click New > Web Site:

Now you can type in a description of the site. Again, this is not critical, this is simply what's you'll see when using IIS. I figure 'test site' will suffice.

Now this is the more important part. This is how we differentiate the sites. The default TCP port for a website to use is 80. We will set this one differently. What this will result in will be our ability to connect to the website with exactly the same URL, but with a different port number appended to it. We should try to pick a port that won't be used by other common applications (you can find a list to avoid here). I'm going to pick 8020. It's right up there, should be safe enough, and not too difficult to remember.

Now comes the time to remember exactly where we made the duplicate of our application by copying to directory. Just type it in here. I also generally disallow anonymous access, even if it is allowed on the production site. The reason for this is that I don't want just anybody stumbling upon the test site, previewing enhancements they're not yet meant to see.

And the final screen we can most likely leave as default. If you have different requirements for your application, just mimic those of the production website.

That's it! IIS is configured! If you've already changed the variables in the test application, you should be able to connect now with the new port number, and see an identical site. Have fun!

Step 4: Code Control

Something that is absolutely non-critical for this project, but yet highly recommended, is code version control. In large scale projects, version control enables each developer in a team to check-out the latest version of desired code, do their work, and check it back in. This is not as necessary when you're all on your lonesome, however the benefit for you is the ability to retain version history of your code, check-in your revised code, and update your live code in an automated way. I personally like CVS (www.cvshome.org) for this, but use the product of your choice.

Conclusion

I highly doubt that I need to convince you now of the need to have both a test and production environment. However, you may be wondering if this is the best way to accomplish that. Well, honestly, there are drawbacks, but probably only two.

This first is the additional resources needed to also house the test code and database. But just remember, you'll probably be the only one - or at least one of very few – people that will be working in the second site. You won't require the same memory and CPU load of the production application, you will just need the same amount of storage space for the code. That's usually not a serious issue. And chances are, that if have a second server for you test code is out of the question, than the company size isn't large enough (not enough people hitting it simultaneously) to worry about the server resources.

The second drawback would be that if you seriously screw something up, and lock up the server, then you've locked up the live application as well. So just be careful.

Aside from that, there are only benefits. So please, once more I entreat you: practice safe coding!

blog comments powered by Disqus