When developing a website...

Question

Very often, I just create a new folder and test things out in there. I use remote upload and then edit and refresh the page to see if it works. Now, one time when I was asked to work on a friend's website, he told me to change the IP for his domain in my HOSTS windows file. He had a clone of his website on another server, so I could edit everything and still visually see my work. Is it ideal to work like this? What's a good strategy for programming when developing websites? e.g. Back up before you begin working, working on the files in a separate directory, etc...

I know everyone has their own style and I understand there's no right way. I'm simply just interested in everyone's common practices and I hope to pick up a few tips here and there and incorporate it to my own style.

Answer 1

Fiddling with the /etc/hosts file is a quick and simple way to simulate a Web address for testing purposes - nothing wrong with that at first blush.

However, if decently done then working on the site shouldn't need that kind of trickery, because all links inside the site should be relative. i.e. if the original site had an address like http://true.app.com and you were testing on a server with address mock.app.com, then you should be able to point your browser at http://mock.app.com and once you're there all the links should work. If the links are absolute (i.e. the page is full of references to true.app.com) then there might be a problem with the design/architecture/structure.

If your friend doesn't have a domain name for his testing server, then the same applies to the numeric address; the links should still work if you start off browsing to http://1.2.3.4.

A valid reason for "faking" the address might be if your site does a lot of back-and-forth with another, and the other site's links send your browser back to your site.

To answer the question: A good strategy is to work with relative links as much as possible; that way, when your friend's business and software get sold to another company, or he goes out of business and has to re-surface under another name you'll have much less work adapting the links - ideally, none.

Answer 2

If you're not already doing it, start using a version control system like git or subversion for keeping track of changes. That way, you'll always be able to revert to an older version if new changes breaks something.

I develop and test changes on my workstation or a development server with a configuration that resembles the web server's config as closely as possible, so that I can be confident that things won't break when I deploy the new version on the web server. I commit my changes as I go, and when I'm satisfied with the new version I deploy it to the web server by checking out the new version on the server.

Answer 3

Pull the site down (if you're going to edit an existing) to your local development web and database server/workstation. Make it run and develop locally. Have the source (code, images, stylesheets, db scripts and so fourth) go into your own version control system.