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 keep an updated db architecture for local development when multiple developers are involved?

In particular, I'm currently experimenting with XAMPP for PHP and was curious how I keep the MySQL DB instance on my local machine in sync when other developers are regularly changing data/db structure.

Is local development only practical when working alone?

Answer 1

Typically you would have a local development server that everyone shares.

Answer 2

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 3

I've found that runing a local web server, with remote DB works best. DB replication/ synchronisation is a pain, so I'd only work with a local DB if I really had to.

Working with a local web server though removes all the annoyance and slowness of uploading pages/ code between changes.

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

I think it's best to have a local setup that is entirely under your control during development in order to ensure that changes made by other developers do not interfere with your own. I have a development and test environment setup locally so I can perform both tasks without needing to take other developers into account. I continually run my tests as I code using autotest, meaning I can be sure that my code is correct and satisfies the correct specification.

After the code base is in order, I deploy to a staging server (which is an environment that is as close to production as possible), and rerun the tests. We also use our stage to run load testing and do user testing.

Answer 6

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 7

• 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 8

Both. Do some integration and unit testing on your development server (which, ideally, should be as similar to your live server as possible, but local), then do some acceptance testing in a QA environment, which should either be the same machine as your live server, or exactly the same setup (hardware, software, etc.) and should be remote.

When it comes to the database part of the question, you could either:

• each have your own copy of the database OR
• keep data/structure in sync by running a centralised script (maybe as part of your build)

Answer 9

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.

Answer 10

FWIW, I'll mention that our setup is like what Mr. Matt described. Each dev gets his own personal sandbox to mess with, with its own webserver and DB. On the verge of release, version-controlled code is snapshot/branched and moved to a staging server which is supposed to mimic the real live environment as closely as possible. Testing ensues, then the release is made to a production environment.

For my own personal (non-work-related) projects, I develop locally, then push live. One or two projects may have an intermediary testing server/environment between development and public/live.

Answer 11

I've been building a site in Ruby on Rails and I've been doing development locally but deploying to a remote machine as often as I can. I read in Agile Web Development with Rails that the more you practice the deploying the better because when it comes time to deploy to production - there will be no surprises.

Answer 12

As far as keeping your DB "in sync" when others are editing it. One way around this is to get your DB schema under version control. This is not as simple as putting your source code under version control, and there are different ways of handling it.

Read this post on Coding Horror:

http://www.codinghorror.com/blog/archives/001050.html

Not so much the post itself but the six articles he links to by K. Scott Allen.

Basically what's described in those articles is a method of baselining the database schema, checking in an .sql file of that baseline, and from there on in you write incremental .sql "change scripts" every time you change the schema. Now everytime a developer checks out or updates a working copy, any outstanding change scripts will be run. You will need to set up some scripts/tools to do that yourself unless you use a framework that does this for you.

Answer 13

Another reason to work locally is that everything runs faster. This translates into faster development. Network lag can be productivity killer!

Answer 14

In my current position, I develop on my own machine. For smaller projects I just use the lightweight web server that ships with Visual Studio. I also have SQL Server 2005 and 2008 set up on my own machine for development and initial testing purposes.

This has worked well for me on the whole; the one issue I've run into is (as others have noted) keeping the databases in sync is kind of a pain. I've recently moved to migrator dot net -- basically a .NET take on Ruby on Rails migrations -- for keeping the local/staging/uat/production databases in sync, and it's making my life much less stressful. A tool like this also makes it easier to work on the database in a team environment, although you must be disciplined enough to use it consistently.

My experiences here have convinced me that local development combined with some sort of db change control process, a continuous integration server, and a good version control system that supports merging (we use TFS) is the best way to go. That lets everyone do their own thing without stepping on someone else, but also makes sure the changes get merged properly.

In my previous job we used IIS on our PCs combined with a dedicated development database and this was a bit of a PITA -- you had to be careful not to run any processes that might take down the database or even mess up the data because it might impact other developers, and IMO, that kind of defeated the purpose of having a development DB in the first place.

Answer 15

I'm a one-man shop; I have both a remote server and a local server.

I use the local server for quick prototyping and the initial development cycle where I'm making lots of changes and need to test them quickly. When it gets to a roughly-alpha stage, I'll set up a custom sub-host for the project and deploy to my server. There are certain features that simply can't be tested locally--i.e. e-mail-based user registration--and so these features get developed on the remote server. Since it's MINE, and not a real deployment, it's still mostly lag-free. Since I have a VPS, I have full control of the development environment on both machines.

Answer 16

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.