March 1, 2004 at 8:19 am
Greetings!
I posted this elsewhere but thought maybe this is a better thread for this question. Apologies for the double post!
I work for a company who's web site I'm developing with a SQL back end. the company's IT group insists on making me update my database on a development server and then replicate it to our QA server and then finally replicate it again to our live server.
This has been troublesome and time consuming - especially since I am building web based tools to edit the db. My feeling is that since I control from my tools what is shown on the site wouldn't it make more sense to edit the db on the live server and do away with the replication across two other servers?
Am I off base with this? Is there a reason why my scheme is bad? They generally claim the replication is for "security reasons"...
Thanks for any insight...
Geo
March 1, 2004 at 8:32 am
Are you actually replicating data changes, or are you actually making data/schema changes, confirming those changes and then manually pushing those changes out?
March 2, 2004 at 3:25 am
Hi,
I think it is good practice to have a 'staging' area (if you like) to house your site and database. You can afford to try a lot more changes without affecting your live server. Is your live server being accessed by the outside world or is it there waiting for the site to be completed ?
It also depends on how your webserver is routed to your internal network.
I have a similar situation where I have a sql driven website. We have internal staging sites (for internet and Intranet) so that any changes to design or content can be viewed before they are implemented on the live servers.
It may be a bit of a bind but knowing that your changes have been QA tested and are working well will be better in the long run.
Cheers
Graeme
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply