this question is coming from a newbie

Generally, all small web developers simply develop a web app on local machine and then move the website to live server via ftp etc.

How can a test server be developed in a way, lets say a separate linode, which runs an exact same replica (including database and everything) of the live website, not visible to public; so the developer can work on it and move files to live server in a blink.

Are there any specific linux software for these purposes ? any tutorials ? I would like to know industry standard work flows to achieve this.

There are two ways to do this that I can think to do this. The more experienced users here may know of more.

1. If your developers have static IP addresses, you can set the firewall on the development server to allow only your developer's connection. Problem is, most people have dynamic IP addresses at home.
2. Set up the development server to allow only localhost connections to the web server, and have your developers setup up a ssh proxy between their browsers and the web server.

Edit: Since I don't know which option you'll choose, I won't go into detail until you say which you'd want.

_________________
Kris the Piki Geeker

I usually recommend handling it like this:
- Setup a subdomain on the same VPS.
* copy all the code to the subdirectory.
* make a copy of the DB and rename it accordingly.
* modify your DB connection info so it points to the test DB.
^^^ be sure NOT to copy the edited DB connection when merging the new code with the existing site.
* do your thing.


I use the above method for major updates or reworking of an entire site. For other changes I use our init stub magic that lets me modify and test code on a live site without disturbing it for site visitors. I can set cookies or URL parameters that give me access to testing & debug functionality. It can display debug info on the page and/or in the browser console, but only to me. It allows me to use alternate source, include or library files & locations, and different owner, site, directory or page config files, etc. This way I don't break the site even with syntax errors, coding or logic errors, or code that crashes.

If I have special nav items for testing or config pages they're added to the menus. It can load alternate or suplemental style sheets. It adds a special javascript file to the page that has some test routines in it. It can even add data or other info to the title attributes of HTML tags if I need it to (hover is my friend).

My DB code wrappers check for test variables and automatically add a prefix to the DB name or table names. My DB error routines only provide an error reference number to a normal site visitor, but in debug mode I get all the gory details.

It's a lot of help when trying to hunt down bugs, testing alternate styles or presentations of the data, adding pages or features, or refining or refactoring code. Without the debug items enabled it functions as a test site for training or a demo site without exposing a client's data.