Development vs. Production and a SaaS project

Ok…so I’m really struggling with this. So, it’s pretty easy, now that I have tested it back and forth, to create an application, particularly with the CB toolbox (heh…CBT) in a sub-directory off the root or as a root in and IIS environment. I have found, however, that pulling in MX Unit has some issue if I’m not in a sub-directory…it gets even worse when the sub-directory is virtual and the code actually sites somewhere else. This is what I typically do using IIS 7.x:

  1. Create a site in IIS and point it’s physical contents to wherever I’ve created my website (typically a shared location where the coldfusion builder project sits)
  2. Create a host header for my dev URL (dev.test.com) for that site and update the hosts file to reflect 127.0.0.1 as an alias for that domain I want to use in the url

It’s just about that easy. With that set, I can now browse to dev.test.com and see CB launch nicely, because IIS is handling the fact that “/” is a host header. I do it this way because when I upload the dev code to a production environment, the production environment is not a shared one, so I create “root” sites all the time and fool dev by using the host headers and IIS. This has always ensured that if I ever had to hard code a relative path starting with a slash that in dev or production, I’d get the same results. Comments welcome on the wisdom of this choice or a better way.

So, in my SaaS application, the clients want to be able to use their own domain names to point to the SaaS application. Again, in IIS, all I would need to do is create another host header record to point to the same site I have already created and bam…you can now get to dev.test.com or www.fred.com and they point to the exact same thing.

However, since I’ve had problems with this “root” site theory and MX Unit, I thought I would simply go back to the directory off the default root site concept…of course MX Unit works wonderfully…but now I have a problem. I can no longer use different domains (host headers) because they would all have to point to the default website and you cannot point the domain directly to a sub-directory. Now, if I were to move that code to production, which is a site root, and added the host headers there, it should work just fine…but I would have no way in dev to test that.

Do you see my dilemma? (knock knock) Is this thing on?

I think my only solution is to have what I’ll call a QA root site local and deploy my dev code to that site and then test it as a root. This does not seem wholly unreasonable to me…but now that I have actually put this all out there, I’m wondering if anyone else develops this way…perhaps there is a better way…or maybe others have run into this problem?

I’d love to get some insight. This may not seem at first glance like it needs to even be in the CB forum…perhaps not…but I thought maybe there was a trick in CB I could use that might help resolve this. I know there is a plugin or interceptor for handling sub-domains. I’ve looked at it and will use it…but it won’t work for me because my aliases will never get to it!

Thoughts, comments, pretty pictures are welcome.

Mike

Adding on.

Not that I like this solution…but I CAN omit a deployment process if I create the alternate test sites and point them to the save development code physical location. Thus, during development, I can use localhost/fred/index.cfm to do my unit testing in builder, but only for one domain. Then, to test multiple domain aliases, launch another browser window and use one of the test domain urls.

This works…but seems as clunky as everything else I’m doing :slight_smile:

Well, spoke a little too soon…the problem with my last update is that when moving from localhost to test domain (host header driven), since the application namespace is the same for all three of them…I always have to reinit the framework (just using a skeleton advanced template site for testing). Again, not that this is horrible…but you know…really annoying if there is indeed a better way to overcome this.

Kinda never mind. I trashed everything and started from scratch…not sure what combination existed that caused the grief but I think I have everything working.

MX Unit still requires the server default url of localhost but running at least the handler tests seems to work ok. I have a virtual directory of “coldbox” configured for the site and for now at least, everything seems to be working correctly. I’m sure more will be revealed and would still love to hear any opinions on local setup vs. deployment.

Mike