问题
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?
回答1:
- 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!
回答2:
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.
回答3:
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.
回答4:
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.
回答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.
回答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.
回答7:
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.
回答8:
Another reason to work locally is that everything runs faster. This translates into faster development. Network lag can be productivity killer!
回答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.
回答10:
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)
回答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.
回答12:
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.
回答13:
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.
回答14:
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.
回答15:
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.
回答16:
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!
回答17:
Typically you would have a local development server that everyone shares.
来源：https://stackoverflow.com/questions/250063/web-developers-is-it-better-to-do-development-on-your-local-machine-or-on-a-re