Web开发人员 – 在本地机器上还是在远程主机上进行开发更好？
在本地机器上进行Web开发而不是在集中式开发服务器上的优缺点是什么？ 对于那些在你的本地机器上进行开发的人，当涉及多个开发人员时，你如何为本地开发保留一个更新的数据库体系结构？
特别是，我正在尝试使用PHP的XAMPP，并且很好奇，当其他开发人员定期更改数据/数据库结构时，如何将本地计算机上的MySQL数据库实例保持同步。
当地的发展只在单独工作时才有效吗？
- 始终，始终发展本地设置。
- 始终使用源代码pipe理。
- 始终将所有内容放在源代码pipe理下，包括数据库模式。
似乎有很多人喜欢有一个中央服务器，每个人都用于开发 – 我不明白为什么你会喜欢在一个共享的环境中，人们作出改变可以中断你的开发过程。
在我的店里，每个人都有自己的开发Web服务器和他们自己的开发数据库（通常位于同一个数据库服务器上 ，但是他们自己的数据库上）。 这样他们完全与其他开发人员隔离开来，不能相互打断。
当他们实现一个function或修复一个bug时，他们会检查他们的代码和匹配的数据库模式，以便作为一个完整的单元提供给其他开发人员。 发布到testing服务器或部署服务器是从源代码库中的标签版本完成的。
稳定和理智！ 当开发服务器是免费的，我不明白为什么你会这样做。
我认为最好是在开发过程中完全控制本地设置，以确保其他开发人员所做的更改不会影响您自己的设置。 我有一个本地开发和testing环境设置，所以我可以执行这两个任务，而不需要考虑其他开发人员。 我使用自动testing代码不断运行我的testing，这意味着我可以确定我的代码是正确的，并满足正确的规范。
在代码库有序后，我将其部署到临时服务器（这是一个尽可能接近生产的环境），然后重新运行testing。 我们也使用我们的舞台来运行负载testing和用户testing。
至于保持你的数据库“同步”，当别人正在编辑它。 解决这个问题的一个方法是在版本控制下获取数据库模式。 这不像将源代码放在版本控制下那么简单，并且有不同的处理方法。
阅读这篇文章编码恐怖：
http://www.codinghorror.com/blog/archives/001050.html
不是这个post本身，而是由K. Scott Allen连接的六篇文章。
基本上这些文章中描述的是一种基线数据库模式的方法，检查该基线的.sql文件，然后在每次更改模式时写入增量.sql“更改脚本”。 现在，每当开发人员检出或更新工作副本时，任何未完成的更改脚本都将运行。 你将需要设置一些脚本/工具来自己做，除非你使用一个框架来为你做这个。
我发现运行本地Web服务器，远程数据库效果最好。 数据库复制/同步是一个痛苦，所以我只能使用本地数据库，如果我真的必须。
尽pipe使用本地Web服务器，但可以消除在更改之间上传页面/代码的所有烦恼和缓慢。
优点到地方：
- 即使networking出现故障也能正常工作
- 你知道机器上的每一个工具
缺点到地方：
- 必须将所有内容同步到部署服务器
- 没有版本控制，你可以打破别人的工作
中央优势：
- 每个人都有相同的工具
- 始终致力于“真实”的内容
缺点中央：
- 如果networking不通，则无法工作
- 您最喜欢的工具可能会丢失
我相信还有更多，但是这些让我想起来了。
在本地机器上开发和“testing”是好的，但是质量testing应该在反映目标环境的系统上进行，即没有安装所有的开发工具等。
这将有助于避免“在我的机器上正常工作”的情况。
FWIW，我会提到我们的设置就像马特先生所描述的那样。 每个开发人员都有自己的个人沙箱，用自己的networking服务器和数据库。 在版本发布的边缘，版本控制的代码被快照/分支，并被移动到应该尽可能模仿真实生活环境的临时服务器。 随后进行testing，然后发布到生产环境。
对于我个人（非工作相关）的项目，我在当地发展，然后推动生活。 一个或两个项目可能在开发和公共/生活之间有一个中间testing服务器/环境。
在当地工作的另一个原因是，一切运行得更快。 这转化为更快的发展。 networking滞后可能是生产力的杀手锏！
在本地主机上testing的一个问题是，你可能会错过本地文件的链接，而不是通过浏览器访问。 我的父亲总是把他的相机俱乐部网站上的链接，如“我的文档\相机俱乐部\照片…”，当我告诉他，他已经把它捣了起来，他会说“这对我有效”。 同样在专业环境中，您可能忘了检查源代码控制的东西，因此它们不会部署在真正的服务器上。
一个妥协的解决scheme可能是拥有VirtualBox或VMWare或Parallels的虚拟机，这样你就可以启动一个虚拟的Solaris，Windows，Mac和/或Linux机器来testing它 – 这将告诉你你的网站在默认浏览器在每一个，再加上你可以确保事实上通过非本地连接工作。 更好的办法可能是部署一个虚拟机，并将其用作Web服务器进行testing。
如果您的基本操作系统是OpenSolaris，那么甚至可以使用ZFS并使用快照，以便在每次testing运行后将虚拟机回滚到其基本状态。
都。 在开发服务器上进行一些集成和unit testing（理想情况下应尽可能类似于您的在线服务器），然后在QA环境中进行一些验收testing，这些validationtesting应该与您现场的机器相同服务器，或完全相同的设置（硬件，软件等），应该是远程的。
当涉及问题的数据库部分时，您可以：
- 每个都有自己的数据库副本
- 通过运行一个集中的脚本来保持数据/结构同步（也许作为你的构build的一部分）
我一直在Ruby on Rails中构build一个站点，我一直在本地开发，但是尽可能经常部署到远程机器上。 我从Rails的敏捷Web开发中了解到，越多地实践部署越好，因为当部署到生产时 – 不会有什么惊喜。
在我现在的位置上，我在自己的机器上开发。 对于较小的项目，我只使用Visual Studio附带的轻量级Web服务器。 我还在自己的机器上安装了SQL Server 2005和2008，以便进行开发和初始testing。
这对我来说总的来说效果不错。 我遇到的一个问题是（正如其他人所指出的）保持数据库同步是一种痛苦。 我最近转移到了migrator的networking – 基本上是一个.NET的Ruby on Rails的迁移 – 保持本地/分段/生产/数据库的同步，这使我的生活减轻压力。 像这样的工具也可以使团队环境中的数据库更容易工作，尽pipe您必须遵守规定才能始终如一地使用数据库。
我的经验使我确信，本地开发与某种数据库更改控制stream程，持续集成服务器以及支持合并的良好版本控制系统（我们使用TFS）相结合是最好的select。 这可以让每个人都做他们自己的事情，而不是踩在别人身上，但也确保这些变化得到妥善的合并。
在我之前的工作中，我们在PC上使用了IIS，并结合了一个专用的开发数据库，这是一个PITA–你必须小心，不要运行任何可能导致数据库丢失甚至弄乱数据的进程，因为它可能会影响其他开发人员和国际海事组织，这种做法首先打败了开发数据库的目的。
我是一个单人店。 我有一个远程服务器和本地服务器。
我使用本地服务器进行快速原型devise，并在最初的开发周期中进行大量的修改，并且需要快速testing。 当它进入一个大致的alpha阶段时，我将为该项目build立一个自定义的子主机，并部署到我的服务器。 有一些function根本无法在本地进行testing – 即基于电子邮件的用户注册 – 所以这些function在远程服务器上得到开发。 由于它是矿井，而不是一个真正的部署，它仍然大部分没有滞后。 由于我有一个VPS，所以我完全控制了两台机器上的开发环境。
通常你会有一个每个人共享的本地开发服务器。
对于这样的情况我总是在开发服务器上完成。 由于没有重新编译。 你总是可以每天得到一个新的数据库快照，并把它放到你的机器上。 或者只是让Web服务器本地化，并将数据库指向开发箱。
我发现在访问集中式开发数据库时使用源代码控制在本地机器上开发代码已经非常成功。 保持多个数据库同步被certificate是困难的。
