40

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?

Sherm Pendley
  • 13,556
  • 3
  • 45
  • 57
Cory House
  • 14,235
  • 13
  • 70
  • 87
  • Exactly the question i sought @Cory House, points!! Im thinking having to run a script on the server each time 3rd party users connect in to launch their latest grunt tasks kind of sucks, server start scripts, etc... With moving to local no need for server scripts per user, just one dev server, where all collaboration is pushed and merged into for pre QA. less path mapping, remote debugging inspection, and live-reload becomes a reality, etc.. So im thinking localmachine pref, but linux box always have to have a way for devs to ssh in and use the box, as a standard though. – blamb Aug 19 '16 at 19:54

17 Answers17

58
  • 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!

Stewart Johnson
  • 14,281
  • 7
  • 61
  • 70
  • That's not really answering the question about *testing*, though. – Bobby Jack Oct 30 '08 at 13:02
  • 1
    The title mentions testing, but the question details talks about development. I see no reason to downvote Stewart just because the question is confused – David Arno Oct 30 '08 at 13:05
  • Ah, good point David. I corrected my title for clarity. I was asking more about dev than testing. – Cory House Oct 30 '08 at 13:09
  • 1
    I think that the point about having a copy of the database here and in source control is really important. Upvote! – Jonathan Adelson Oct 30 '08 at 13:44
  • 1
    I would even add a local test environment, similar to the dev test environment. Upvote! – Schalk Versteeg Oct 30 '08 at 13:55
  • What a brilliant and extensive answer, Stewart! There also hidden benefits of local development. Due to differences in developers' environments it is easier to detect software flaws and/or setup errors. Also, it helps to have one or two step deployment procedure which is good for testing. – Michał Niedźwiedzki Oct 30 '08 at 14:19
  • And don´t forget the release management. You must know always what is your version in integration, in test, in uat in production, etc. – Mariano Oct 30 '08 at 19:40
  • I agree with you almost completely, except in 2 instances: (1) you work from multiple machines and (2) you are the sole developer on a project. – Darryl Hein Feb 07 '09 at 05:49
7

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.

Codebeef
  • 43,508
  • 23
  • 86
  • 119
7

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.

Cœur
  • 37,241
  • 25
  • 195
  • 267
noob source
  • 375
  • 2
  • 9
6

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.

David Arno
  • 42,717
  • 16
  • 86
  • 131
5

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.

warren
  • 32,620
  • 21
  • 85
  • 124
  • "Synch to the deployment server" -- shouldn't this be a release from a labelled version of your product from source control, regardless of whether you're local developing or central developing? (i.e.: no difference). – Stewart Johnson Oct 30 '08 at 13:13
  • it should be, yes; hence the comment about if you're not using source control you're going to have major issues – warren Oct 30 '08 at 13:16
  • Well then it's not really just a "cons to local" then -- your list is a bit misleading. – Stewart Johnson Oct 30 '08 at 13:28
  • I'll also add: if your network goes down often enough in your workplace for it to figure on your pros/cons list then you've got bigger problems than your choice of local dev or central dev server. – Stewart Johnson Oct 30 '08 at 13:29
  • I know many folsk who do development at home, then upload via their DSL/Cable modem/dial-up to a web server somewhere. – warren Oct 30 '08 at 13:42
  • using command-line editors (at least) on a shared server, though, will report if someone else has a lock on a file because they're updating it; I guess that's a primitive form of source control - which makes my list not misleading – warren Oct 30 '08 at 13:43
  • ok, your list is getting worse and worse if you're using file locks as source control. :-/ – Stewart Johnson Oct 30 '08 at 13:44
  • Clarification: I'm not saying your points aren't valid, they're just valid in really uncommon situations. It's so easy to set up identical local dev servers for everyone (think: vmware) I don't see how you could justify anything else. – Stewart Johnson Oct 30 '08 at 13:45
  • why I down voted? this answer was a thoughtful review for 2008, so kudos! with all respect to this author and authors of similar answers: times have changed drastically, and the accepted thinking on this question has, as well. I started to describe more here, but there was too much to say. see my answer on this page, but especially see the accepted answer. – Kay V Oct 30 '18 at 18:26
  • @KayV I heartily disagree: you should pretty much *always* be developing on your local machine (using source control, of course). – warren Oct 30 '18 at 19:21
  • hi @warren - thanks for the response. please note that in fact we are in agreement. I down-voted this answer. Certainly my 2nd sentence might create confusion: I didn't want to trash someone for thinking one way in 2008 when they most likely have since come to think the way you and I do. I invite you also to downvote this answer, upvote the accepted answer and read the answer I penned yesterday. Comments welcome! – Kay V Oct 31 '18 at 14:13
  • @warren - just realized you authored this answer. If you clarify your support of developing locally in your answer, I'll happily reverse my downvote! (I suspect you didn't mean to leave the ambiguity I managed to read in your answer). – Kay V Oct 31 '18 at 14:24
  • @KayV - there was no ambiguity 10 years ago when I wrote it ... and I don't see how you see any today :) – warren Oct 31 '18 at 20:24
  • @warren fair enough. let me know if my point of view is of any value to you. I'm a careful reader. there might be something. in any case, you wrote a very succinct and useful comparison of the pros and cons. I'll leave my downvote as is for now for the simple reason that I'm still misreading your conclusion as ambiguous. Should I assume that you down-voted my writeup below? if so, would you mind offering some feedback on it? (I also believe thanks are due you for the civility of your input so far in this discussion.) – Kay V Oct 31 '18 at 23:07
  • @KayV - I didn't leave a "conclusion": I left a list of pros and cons. Leave the downvote, or not - that's up to you :) – warren Nov 01 '18 at 04:06
5

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.

DilbertDave
  • 3,406
  • 3
  • 33
  • 42
4

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.

Pistos
  • 23,070
  • 14
  • 64
  • 77
3

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

Even Mien
  • 44,393
  • 43
  • 115
  • 119
1

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)
Bobby Jack
  • 15,689
  • 15
  • 65
  • 97
1

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.

Paul Tomblin
  • 179,021
  • 58
  • 319
  • 408
1

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.

Owen
  • 22,247
  • 13
  • 42
  • 47
1

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.

David
  • 5,651
  • 2
  • 16
  • 4
1

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.

Nathan Strong
  • 2,360
  • 13
  • 17
1

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!
Kay V
  • 3,738
  • 2
  • 20
  • 20
0

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.

nportelli
  • 3,934
  • 7
  • 37
  • 52
0

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.

Natron
  • 71
  • 1
-1

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

Brian Knoblauch
  • 20,639
  • 15
  • 57
  • 92
  • Why not? You seem very opinionated; could you clarify why people should not do this? – Aron Rotteveel Oct 30 '08 at 13:00
  • Because if you have a bunch of people sharing a server you end up with everyone stepping on each other's toes -- you can't restart the server, make big changes, etc. It's so cheap and easy for each developer to have their local server I don't see why you wouldn't do it. – Stewart Johnson Oct 30 '08 at 13:11
  • Why do you need to restart the server (I assume you mean the hardware)? What 'big changes' can't you make? – Bobby Jack Oct 30 '08 at 13:14
  • You want a shared server exactly for those reasons. You can see what happens when you interact with what everyone else is doing. – Brian Knoblauch Oct 30 '08 at 13:15
  • 1
    Wait, what? How does people making code changes and breaking your development process mirror the real world? – Stewart Johnson Oct 30 '08 at 13:16
  • 1
    Pull in from source control, merge changes locally, test locally, do they work? yes / no, No need for a shared server. You shouldn't be working on the live code on the server anyway, that should just contain the last tested and working bunch code. – Sekhat Oct 30 '08 at 13:21
  • @Killersponge: completely agree -- see my answer for more detail on how we set up for local dev. – Stewart Johnson Oct 30 '08 at 13:23
  • Our developers have their own VMware with their own copy of the code, data, daemons (httpd, postgresql, memcached). Then there's a communal dev server which runs trunk, a staging server, and the production servers. – noob source Oct 30 '08 at 13:30
  • @Bobby Jack -- big changes like database schema changes that will break everyone's code. Or what if you accidentally write a race condition and lock up the server? Everyone is affected. – Stewart Johnson Oct 30 '08 at 13:37
  • @Stewart, big changes like schema are another good example of why it should be done on a common server. You'll know exactly what it breaks sooner. I think our difference is that I'm in a continuous integrations environment. If not doing it this way, I see where your way would make sense. – Brian Knoblauch Oct 30 '08 at 18:14
  • @Brian - making a breaking change and causing all your developers to wait while it's unbroken is expensive. And unnecessary. – Stewart Johnson Oct 30 '08 at 22:33