Web开发人员 - 在本地计算机或远程主机上进行开发是否更好？

Question

在本地计算机上而不是在集中式开发服务器上进行Web开发的优点/缺点是什么？对于那些在本地机器上执行dev的人，当涉及多个开发人员时，如何为本地开发保留更新的数据库体系结构？

特别是，我正在尝试使用XAMPP for PHP，并且很好奇当其他开发人员定期更改数据/数据库结构时，如何让我的本地计算机上的MySQL数据库实例保持同步。

本地开发只在单独工作时才有用吗？

Answer 1

• 始终，始终在本地设置上进行开发。
• 始终使用源代码管理。
• 始终将所有内容置于源代码管理之下，包括数据库架构。

似乎有很多人喜欢拥有一个每个人都用于开发的中央服务器 - 我真的不明白为什么你更喜欢在共享环境中进行更改的人可能会中断你的开发过程。

在我的商店里，每个人都有自己的开发Web服务器和他们自己的开发数据库（通常位于同一个数据库服务器，但他们自己的数据库）。这样他们就完全与其他开发人员隔离，不会互相打断。

当他们实现功能或修复错误时，他们会检查代码和匹配的数据库架构，以便其他开发人员可以将其作为一个完整的单元使用。测试服务器或部署服务器的发布是从源代码存储库中的标记版本完成的。

稳定而且理智！当开发服务器空闲时，我不明白你为什么要这样做呢！

Answer 2

我认为在开发过程中最好有一个完全由您控制的本地设置，以确保其他开发人员所做的更改不会干扰您自己的更改。我在本地设置了开发和测试环境，因此我可以执行这两项任务，而无需考虑其他开发人员。我在使用自动测试编码时不断运行测试，这意味着我可以确保我的代码是正确的并且满足正确的规范。

在代码库有序后，我将部署到登台服务器（这是一个尽可能接近生产的环境），然后重新运行测试。我们还使用我们的阶段来运行负载测试并进行用户测试。

Answer 3

在其他人编辑数据库时保持数据库“同步”。解决此问题的一种方法是将数据库架构置于版本控制之下。这并不像将源代码置于版本控制之下那么简单，并且有不同的处理方式。

阅读关于Coding Horror的这篇文章：

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

不是这篇文章本身，而是他与K. Scott Allen联系的六篇文章。

基本上，这些文章中描述的是一种对数据库模式进行基线化的方法，检查该基线的.sql文件，并在每次更改模式时编写增量.sql“更改脚本”。现在，每当开发人员签出或更新工作副本时，都会运行任何未完成的更改脚本。您将需要设置一些脚本/工具来自己完成，除非您使用为您执行此操作的框架。

Answer 4

我发现使用远程数据库运行本地Web服务器效果最佳。数据库复制/同步很麻烦，所以如果我真的必须使用本地数据库，我只能使用它。

使用本地Web服务器可以消除在更改之间上传页面/代码的所有烦恼和缓慢。

Answer 5

本地优点：

• 即使网络出现故障也能正常工作
• 你知道机器上的每一个工具

对本地的弊端：

• 必须将所有内容同步到部署服务器
• 没有版本控制，你可以破坏他人的工作

中心的优点：

• 每个人都有相同的工具
• 始终致力于“真实”内容

中心的缺点：

如果网络出现故障，
• 无法正常工作
• 您的“最爱”工具可能会丢失

我确信还有更多，但这些都会立即浮现在脑海中。

Answer 6

在本地计算机上开发和“测试”是好的，但是应该在反映目标环境的系统上执行质量测试，即不安装所有开发工具等。

这有助于避免“它在我的机器上运行良好”的情况。

Answer 7

FWIW，我会提到我们的设置就像Matt先生描述的那样。每个开发人员都有自己的个人沙箱，有自己的网络服务器和数据库。在发布的边缘，版本控制的代码是快照/分支并移动到临时服务器，该服务器应该尽可能地模仿真实的实时环境。随后进行测试，然后发布到生产环境。

对于我自己的个人（非工作相关）项目，我在本地开发，然后推送。一个或两个项目可能在开发和公共/现场之间具有中间测试服务器/环境。

Answer 8

在本地工作的另一个原因是一切运行得更快。这转化为更快的发展。网络滞后可能是生产力的杀手！

Answer 9

两者。在您的开发服务器上进行一些集成和单元测试（理想情况下，应尽可能与您的实时服务器类似，但在本地），然后在QA环境中进行一些验收测试，该环境应该与您的生活在同一台机器上服务器，或完全相同的设置（硬件，软件等），应该是远程的。

当谈到问题的数据库部分时，您可以：

• 每个都有自己的数据库副本或
• 通过运行集中式脚本（可能作为构建的一部分）使数据/结构保持同步

Answer 10

在localhost上测试的一个问题是，您可能会错过链接到本地​​文件而不是通过浏览器访问的内容。我的父亲总是在他的相机俱乐部网站上放置链接，例如'a href =“C：\ My Documents \ Camera Club \ Photos ......”，当我告诉他他已经把它搞砸了，他会说“这对我有用”。同样在专业环境中，您可能会忘记检查源代码控制，因此它们不会部署在真实服务器上。

一个折衷解决方案可能是拥有虚拟机，VirtualBox或VMWare或Parallels，以便您可以启动虚拟的Solaris，Windows，Mac和/或Linux机箱进行测试 - 这将显示您的网站的外观每个浏览器上的默认浏览器，以及您可以确保实际上通过非本地连接工作。更好的方法可能是部署一个VM，并将其用作Web服务器进行测试。

如果您的基本操作系统是OpenSolaris，您甚至可以使用ZFS并使用快照，以便在每次测试运行后将VM回滚到其基本状态。

Answer 11

我一直在Ruby on Rails中构建一个站点，我一直在本地进行开发，但是我尽可能多地部署到远程机器上。我在使用Rails阅读敏捷Web开发时认为，部署更好的部署越多，因为当部署到生产时 - 不会有任何意外。

Answer 12

在我目前的职位上，我在自己的机器上开发。对于较小的项目，我只使用Visual Studio附带的轻量级Web服务器。我还在我自己的机器上安装了SQL Server 2005和2008，用于开发和初始测试。

这对我整体来说效果很好;我遇到的一个问题是（正如其他人所说）保持数据库同步是一种痛苦。我最近搬到了migrator dot net - 基本上是一个.NET on Ruby on Rails迁移 - 用于保持本地/ staging / uat / production数据库同步，这让我的生活压力更小。这样的工具也使得在团队环境中处理数据库变得更加容易，尽管你必须足够自律以便一致地使用它。

我的经验使我确信本地开发与某种数据库更改控制流程，持续集成服务器以及支持合并（我们使用TFS）的良好版本控制系统相结合是最好的方法。这样每个人都可以在不踩到别人的情况下做自己的事情，但也要确保更改能够正确合并。

在我之前的工作中，我们在我们的PC上使用了IIS并结合了专用的开发数据库，​​这有点像PITA - 您必须小心不要运行任何可能会占用数据库的进程甚至搞砸了数据，因为它可能会影响其他开发人员和IMO，这种方式首先打败了开发数据库的目的。

Answer 13

我是一个单人商店;我有一个远程服务器和一个本地服务器。

我使用本地服务器进行快速原型设计和初始开发周期，我正在进行大量更改并需要快速测试它们。当它进入大致alpha阶段时，我将为项目设置一个自定义子主机并部署到我的服务器。某些功能根本无法在本地进行测试 - 即。基于电子邮件的用户注册 - 因此这些功能在远程服务器上开发。由于它是MINE，而不是真正的部署，它仍然主要是无滞后的。由于我有VPS，因此我可以完全控制两台机器上的开发环境。

Answer 14

本地开发。注意答案的日期相反。毫无疑问，它们已经过时了。

让我们保持记录。十年后，这个问题仍然存在，有些人继续提出过时的概念。阅读接受的答案。可以肯定地说，这几天无可争议。在过去的十年中，各种答案中提到的对当地发展的“弊端”都得到了很好的解决。

但是赞！这个问题的一些答案描述了生产上的发展，这是风险的严重升级。要明确：严格避免在生产上发展。 （我相信那些开发人员将不再拥护它。对过时的答案的投票可能应该过期。也许那些投票的人会回来并表明他们的最新想法。）

推荐的解决方案，超出可接受的答案中的范围：

• 如果可以的话，对您的开发工作流程进行容器化（例如尝试Docker）。
• 避免将数据库从本地推送到远程；找到一个基于源代码管理的更多增量，受管过程。 configuration management initiative in Drupal 8提供了一个有趣的示例。
• 对于源代码控制，请考虑使用Git。如果您推迟采用源代码管理管理解决方案，那么就不再延迟！

Answer 15

我发现在访问集中式开发数据库时使用源代码控制在本地计算机上开发代码效果很好。保持多个DB同步是很难的。

Answer 16

对于像我这样的情况，我总是在开发服务器上完成它。由于没有重新编译。您每天都可以获得一个新的数据库快照，并将其下载到您的计算机上。或者只是让Web服务器本地化并将数据库指向开发框。

Answer 17

通常，您将拥有一个每个人都共享的本地开发服务器。