[Neara]

I have a production server up and running, and another server with newly designed pages. When we will finish re-designing all the pages, this new server will be the production server. The application is written in Django 1.4, Python 2.7 .


What I generally would like to do is go to this other server check if it has the url that was requested and if so then present a message on the screen informing a user that new version of this page exists and if he wants, he can click here and see the new version.

What is the best approach to do it?

Any help would be very much appreciated

[Lemur]

I would honestly just go ahead and change it. Users have been shown, time and again, to absolutely despise any form of popup or hindrance to browsing. In Web, you have under 2 seconds to convince a user that your site is worth their precious time, and a banner of any sorts that pops up noticeably enough to let a user know it's updated will kill your page in traffic.

[Neara]

I agree about that. I, myself, don't like any banners at all and said as much, non the less it is still up to me to make it happen. I don't intend to make it banner-like, something more subtle, maybe just a sentence in green or some sign that will flicker for a few secs. How it will be shown (UI wise) is still to be determined, I'm more on the side of coding it into existence

The idea that I have right now is to add a url check in base.html template in JS. Something on the lines of get and ,if a response is 200, show the element (what ever that element will be).

What I would like to know is if that is the right way to do it? Or maybe JQuery or Django have plugins to do it and I just don't know about them.

[Atli]

Is it a requirement that the user be presented with the choice? I'd be willing to be that 99.9% of your users would much rather that you make this choice for them then be presented with a choice of any kind. And if you do present them with a choice, they'll likely just ignore it to avoid having to deal with it.

Will some of the old pages not have a corresponding page in the new site? You say that when you "finish re-designing all the pages" you will make the new server the production site. What will happen to the old server? Will it still be there, under the same URL, providing the old content?


What I would do if this were one of my sites, is that I would simply swap out the servers, and have any incoming request for content on the old site be automatically replaced by the new content, without changing the URL.

[Neara]

Will some of the old pages not have a corresponding page in the new site?
Yep, not yet.

What will happen to the old server?
Either caching or will be used for another project. What I didn't say, and I guess I should have, is that both servers use same database. If old servers' domain is mysite.com, new server currently uses dev.mysite.com, aside from that all urls are the same. In the end, URLconf will be the same. What changes is the front end, no changes to back end.


What I would do if this were one of my sites, is that I would simply swap out the servers, and have any incoming request for content on the old site be automatically replaced by the new content, without changing the URL.
How? That's exactly what I'm asking

[sbromley]

Routing a request to a certain server instance is more of a networking question, and something I don't know very much about.

HOwever, it sounds like you could solve this problem easily by setting up a simple version system. Have the old code be version 0 and the new code be version 1. Then based on what the user decides you can programatically add a query param to the request uri. Then in your controller you can flex which code you run based on the version query param.

[Neara]

Yeah,that is the idea.
Generally (w.o code samples, yet):
I will have a javascript code running on every new page load, requesting the url from new (dev) server. The response from dev will hold a meta key saying what is the state of that page. If the state is ready, will show a button "click here for new version" with href attribute holding current url with new=true.
On server, will be a middleware checking if the url holds new=true, and if that is the case, will forward the response to dev server.Production server, in this case, will be a proxy.

I don't want the user to finally find himself on another domain. The domain has to stay the same.

[modi123_1]

Wait, what is going on here? No.. you shouldn't have to swap domains or what not.. just back up the original site and then copy the files from devbox to prodbox. I am not sure why there is this giant deviation from a pretty standard procedure.

[Neara]

Hehe..that is what i was trying to find out, if there is any standard procedures for this case.

[modi123_1]

I don't know what your company's procedures are but they can be as simple as:

• open up folder on prod.
  
• copy all content out to a shared drive for backup.
  
• label appropriately
  
• grab all the files in devbox
  
• drag into prodbox
  
• over write as needed.

As long as you don't jack up any configs between them a webpage on prod shouldn't differ from dev... this isn't rocket surgery.

[Neara]

Not a company. Big open source project, written in Python on Django (MVT kind). Same models, new views and templates. Not a static content. No data is saved on dev. Dev queries same db and just represents the data in another way. Normative user will browse the site as it is. Once in a while, doesn't matter why, a user will want to see a new version of a page he is on. This is the problem I'm looking to solve. Exactly as sbromley says, it is a question of what code to run to respond to the request. One code is on prod and another on dev. So, once in a while I want to call a view on dev and represent it, without changing the url a user sees. A user shouldn't know that he is on another server.

[modi123_1]

That is a horrible idea because it trashes the bright line between a dev box and a production box. The production box is always the front facing user box. All the stable code, bug fixes, and gold plating up to a certain point. It shouldn't change much... the dev box is usually full of half formed and broken bits of code being worked on. Never should the two meet. If there is some sort of page on the dev box the customer needs to see then you check it in, build everything, and push a new version of production out. That's why version numbers have a major number and a minor number.

[Atli]

If you really need to swap between server computers, like say if your new site is using a different HTTP server, it's a hardware upgrade, or if there some other major platform difference, then you can just redirect the domain name. Change the DNS record for the "example.com" domain from the old computer to the new computer. Problem solved! All requests for content from the old server will now be handled by the new server.

It's also possible (probable, even) that your current server is behind a router of some sort, in which case you can just hook the new server up to that same network and redirect port 80 traffic there instead. (The standard port-forwarding scenario.)

Neara said:

Normative user will browse the site as it is. Once in a while, doesn't matter why, a user will want to see a new version of a page he is on. This is the problem I'm looking to solve.

This is what I don't get. Why would a user "want to see a new version"? Why are you giving the user a choice between the new and the old version? - You should just be replacing the old version with the new version. No user interaction required; no choice to be made.

The simplest way to do that, like modi123_1 says, it to just replace the old code on the old server with the new code. (After backing the old code up, obviously.)