Effective web development depends on having a good environment for working on code, and seeing your changes immediately, while making it easy to test and deploy changes.
There are a number of ways to accomplish this:
1. Develop on your live website
I’d guess that the vast majority of website owners build their website on their live server. It is quite simply the path of least resistance and least cost as it doesn’t require anything other than your main website and some caution (not to mention total disregard for your website visitors.)
This is an effective method only if you don’t have a lot of visitors, or at the very least don’t care if your visitors see an occasional hiccup or error message.
As soon as your website reaches any level of complexity, traffic, and/or revenue, this simply becomes a bad idea.
2. Develop in a secondary directory on your production domain
The easy next step from developing on the live server is to copy the site into a subdirectory on your server. This is easy as it requires no additional setup other than creating a new directory and copying files over.
For example if your website is at www.bagowetmice.com, you might do all your development in a directory called www.bagowetmice.com/dev/
This can get tricky, however, as you’re forced to worry about the url and directory structure of your website. Or you must use tricks with a base url meta tag in the header of every page.
Therefore the act of copying everything into the root directory can be a difficult one. Did any of the directory structure change? Are there any link references to /dev/?
This is generally unmanageable for all but small websites.
3. Develop on a copy of your website hosted on a subdomain
What the above #2 has going for it is a entire copy of your production site in a second location. If we add to that a new domain, or subdomain, so the development site lives in the root directory, we eliminate all of the directory path issues.
Set up a subdomain. Using our example, set up a second site on dev.bagowetmice.com . Most hosting providers will offer this for free, or for a small setup fee.
Now, you can do all your development work in an environment that completely mirrors your production environment. And as long as you always use relative urls (without specifying the domain), copying your site into the production server is a quick, easy, and seamless process.
If you have a database for your website, you may also want to create a copy of that as well and use the test copy for development. If you do this, you need to be careful to always point the production site at the production database and the development site at the test database. Most web developers create a configuration file (e.g., config.php) that contains all the database connection information. This file gets included into the top of every other file on the site. By separating out this configuration information, there is only a single file that you need to worry about keeping intact when copying a site over.
If you’re a single developer of a website, or even one of two developers, this can be a very effective method of managing web development projects. It is easy to set up, and testing is very easy as all changes occur live on a real web server.
It is obviously dangerous for two people to be editing files in the same development server, but with some communication can be managed effectively. With heavy development, or more than two people, however, this can become problematic.
4. Develop on a local copy of your entire production environment
“Real” web developers who work on large teams and large websites have a very structured work environment. Each developer has their own personal working copy of a website where they do their work. And periodically, they copy their modified files up to a central code repository.
You don’t have to work in a big formal development team to take advantage of these methods. It’s pretty easy to set up an industrial strength environment that will make your work more structured, and therefore more efficient and less error-prone.
While you could fairly easily set up each developer with their own copy of a website using the method in #3 above, it’s actually not at all difficult to set up a local environment regardless of the operating system you’re working on. The added benefit of working locally is that you don’t actually need an internet connection to get your work done.
Most Linux distributions come with Apache/MySQL/PHP installed (aka LAMP). And while you can install these tools individually on OS X and Windows, there are freely available packages that install and configure these tools automatically (aka, MAMP and WAMP).
See the following resources for these tools:
WAMP – Windows Apache Mysql PHP
MAMP – Macintosh Apache Mysql PHP
Once you get your webserver and database running locally, copy your website and database down and get them running. There are some neat tricks that you can do with local name resolution to set up a fake domain, like bagowetmice.dev. With that you can develop and test with a real (fake) domain that makes it easy to access and remember instead of using IP addresses.
Finally, get some sort of software version control for web development set up, like Subversion, to manage changes to files (especially if there’s more than one of you) and you’re really cooking.
Next, I’ll write up the procedure for setting up a local development environment on Mac OS X.
What method do you use?
