I’ve found out a lot about other people’s development practises whilst building and supporting Perch. One thing I never expected to see, and genuinely surprised me, was to find that not only are people actively building sites by working live on production servers, but they’re frequently developing new sites in a subfolder of an existing live site. This must stop.

Don’t develop on live servers

I really shouldn’t need to say this, but working directly on live server is a bad idea. Despite the fact that any mistake you make (and let’s not pretend we don’t all make them) could affect the functioning of live websites, it means you’re not making proper use of version control systems. If you screw up and need to go back to a known working copy, you can’t. If you accidentally delete the wrong thing, it’s gone. Couple in the fact that you’re working live means that any mistake is not just an annoying loss of work, but could result in loss of business for your client.

Don’t build a new site in a subfolder

I couldn’t quite believe how prevalent this way of working seems to be. It’s a terrible idea to develop a new site in a subfolder of an existing site, with the intention of then putting it live by moving all the files up one level.

Why is this so bad? Web pages are all about relationships. The relationship between pages (it’s a hypertext system!) and the relationship between a page and its various resources such as images, stylesheets and so on. These are expressed as links and resource paths in your pages. Once you’ve developed and tested your new site and are ready to go live, the thing you should avoid doing at all costs is to shift the pages around your site, possibly breaking all those links. Why go through the trouble of testing at all, if you’re about to make such a monumental change that will require retesting again. On a now-live site. It’s crazy. Stop doing it.

Here’s what to do instead

Here’s the most basic workflow you should be adhering to. You can get a lot more complex, but this is a minimum.

Firstly, if your site will ultimately be at the top level of a domain (as most typically are) that’s how you should develop. Set up a local web server (either a dedicated physical server, a virtual machine, or simply something like MAMP Pro or XAMPP) and build your site as an independent website on that server.

Use source control. Be that subversion, git, even CVS – whatever works best for you, but use something. Find which systems your existing editor has support for and start there. Use a hosted service like Beanstalk if you prefer. Commit your changes regularly.

When you’re ready to share the site with the client or other team members, deploy it to a proper site of its own. Not to a subfolder. This could be a subdomain of the existing site like newsite.client.com or you could keep it under your own control with something like client.mycompanytestsites.com. This is a great use for one of those cheap reseller hosting accounts. The important thing is that it’s in a proper site of its own, just as it will be when the site is put live.

The above will cost very little in terms of out actual outlay, but will save you time in the long run, as well as making your development processes far more robust and professional.