Jump to content

Recommended Posts

I am developing a 20 page social network site - my first full site after various bits of training / part bits of sites.

 

How should I set-up/design the site so going forward I can test it / update / improve. Especially for testing new ideas & updates to pages before making them live.

 

How would Facebook for example do it? They obvisouly launch updates to pages. How is their process done. They dont just update live and hope for the best - it is obviously tested first.

 

My idea: create site at www.sitename.com and also have duplicate at test.sitename.com - all testing can be done at test.sitename.com (which is protected by .htaccess password) - before quickly moving it all to www.sitename.com where it is live (swopping over as need) - (obviosuly code needs to support both www. and subdomain, to ensure don't need two pages for both) (but must support https: which can be funny on subdomains)

If you have a high traffic site and you do develop locally (which is what I would do), I would upload all of the files first, and then merge them all at once.  My upload speed is horribly slow, so if I uploaded them 1 at a time, some users might see weird things while I was in the process of uploading files.

 

Just a thought.

Another option is, let them know of downtime at like midnight, then "turn off" the site while you upload the files and do a test for the production site. This way users do not get weird errors, it is expected, and you can upload/test your site first.

 

Always keep a backup of the old site just in case something went horribly wrong and you have to revert and do more testing locally.

 

But yes, developing locally is the way to go. If you have many people developing I would look into Subversion. Great software.

My upload speed is horribly slow, so if I uploaded them 1 at a time, some users might see weird things while I was in the process of uploading files.

 

Use version control (svn, git, mercurial, etc.) and do a checkout on the production server. The server that hosts the repository and your production server should both have high speed connections. When you've committed the changes you would just update the working copy on the production server.

 

Always keep a backup of the old site just in case something went horribly wrong and you have to revert and do more testing locally.

 

That's where version control comes in.

 

 

Anyway, I think setting up a staging server is a good idea. This should of course use the exact same configuration as your production server does. You could write unit tests and functional tests and then have a continuous integration server on the staging server that runs all your automated tests. If it fails then it's back to work, if it doesn't fail then you can update the production server's working copy.

 

I still think you should develop locally though. It saves you from uploading every single change and if your connection dies then you can keep on working.

 

but must support https: which can be funny on subdomains

 

Why? Just get a certificate per (sub)domain or get a wildcard certificate.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.