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 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 2

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:

https://blog.codinghorror.com/get-your-database-under-version-control/

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 3

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 4

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 5

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 6

Develop locally. Note the dates on answers to the contrary. Make no mistake that they are very out of date.

Let's set the record straight. This question continues to be asked a decade later, and some folks continue to promulgate outdated notions. Read the accepted answer. Safe to say it's incontrovertible these days. The 'cons' to local development mentioned in various answers have been reasonably well resolved in the intervening decade.

But YIKES! Some answers to this question describe developing on production, a serious escalation of the risks. To be clear: strictly avoid developing on production. (I'm confident those developers no longer advocate it. Upvotes on outdated answers should probably expire. Perhaps those who voted will come back and indicate their latest thinking.)

Recommended solutions beyond those mentioned in the accepted answer:

• Containerize your development workflow if you can (e.g. try Docker).
• Avoid pushing databases from local to remote; find a more incremental, managed process based in source control. The configuration management initiative in Drupal 8 provides an interesting example.
• For source control, consider Git. If you've put off adopting a source control management solution, delay no longer!