Web developers - Is it better to do development on your local machine or on a remote host?

Question

What are the pro/cons of doing web development on your local machine rather than on a centralized development server? For those that do dev on your local machine, how do you kee

Answer 1

I have found that developing the code on the local machines using source control while accessing a centralized development DB has worked out great. Keeping multiple DB's in synch proved to be hard.

Answer 2

Developing and 'testing' on the local machine is Ok but quality testing should be performed on a system the reflects the target environment, i.e. without all of the development tools etc installed.

This will help avoid the 'well it works on my machine' situations.

Answer 3

For a situation like that I've always done it on a development server. Since there are no recompiles. You could always get a new DB snapshot everyday and bring it down to your machine. Or just have the web server local and point the DB to the dev box.

Answer 4

Pros to local:

• works even if the network goes down
• you know every tool on the machine

Cons to local:

• have to synchronize everything to the deployment server
• without version control you can clobber others' work

Pros to central:

• everyone has identical tools
• always working on "real" content

Cons to central:

• can't work if network is down
• your "favorite" tool(s) may be missing

I'm sure there are more, but these come to mind right-off.

Answer 5

• Always, always develop on a local setup.
• Always use source control.
• Always put everything under source control, including the database schema.

There seems to be a lot people who like to have one central server that everyone uses for development -- I don't really understand why you would prefer to be in a shared environment where people making changes can interrupt your development process.

In my shop everyone has their own development web server and their own development database (often colocated on the same database server, but their own database). That way they're completely insulated from the other developers and can't interrupt each other.

When they implement a feature or fix a bug they check in their code and the matching database schema so that it's available to other developers as a complete unit. Releases to the test server or the deployment server are done from a labelled version in the source code repository.

Stable and sane! I don't see why you'd do it any other way when the development servers are free!

Answer 6

One problem with testing on localhost is that you might miss things that are links to local files rather than accessible through the browser. My father was always putting links on his camera club web site that were things like 'a href="C:\My Documents\Camera Club\Photos...", and when I'd tell him that he'd farked it up, he'd say "it worked for me". Similarly in a professional environment, you might have things that you forgot to check into source code control, and so they won't get deployed on the real server.

One compromise solution might be to have VMs, either VirtualBox or VMWare or Parallels, so that you can fire up a virtual Solaris, Windows, Mac and/or Linux box to test it - that will show you how your site looks in the default browsers on each, plus you can make sure things actually work through a non-local connection. Even better might be to have a VM that you deploy to, and use that as your web server for testing.

If your base OS is OpenSolaris, you can even use ZFS and use snapshots in order to rollback your VMs back to their base state after each test run.