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

40

在本地机器上进行Web开发与在集中式开发服务器上进行开发相比,有何优缺点?对于那些在本地开发的人来说,当涉及到多个开发人员时,您如何保持本地开发的最新数据库架构?

特别是,我目前正在尝试使用XAMPP进行PHP开发,并且很好奇其他开发者定期更改数据/数据库结构时我如何将MySQL数据库实例保持同步。

只有在独自工作时,本地开发才是可行的吗?


正是我想问的问题@Cory House,谢谢!我在考虑每次第三方用户连接时都要在服务器上运行脚本来启动他们最新的grunt任务,这样有点糟糕,需要服务器启动脚本等等...转移到本地后,每个用户都不需要服务器脚本,只需要一个开发服务器,所有的协作都被推入并合并到预先进行QA的服务器中。路径映射、远程调试检查和实时重新加载变得更加简单等等...所以我认为优先选择本地机器,但是Linux服务器始终需要一种方式让开发人员可以通过ssh登录并使用它,这是一个标准。 - blamb
17个回答

58
  • 始终在本地环境上进行开发。
  • 始终使用源代码控制。
  • 始终将所有内容(包括数据库架构)放入源代码控制下。

有很多人似乎喜欢使用一个中心服务器供所有人进行开发 - 我真的不明白为什么你会更喜欢处于共享环境,让进行更改的人干扰你的开发过程。

在我的工作室中,每个人都有自己的开发 Web 服务器和开发数据库(通常位于同一台数据库 服务器 上,但是它们都是独立的)。这样他们就完全隔离于其他开发人员之外,不会相互干扰。

当他们实现一个功能或修复一个错误时,他们会将他们的代码和相应的数据库架构一起提交,以便其他开发人员可以获得一个完整的单位。测试服务器或部署服务器的发布是从源代码库中标记的版本进行的。

稳定而明智!当开发服务器是免费的时候,我不明白为什么你会以其他方式做。


这并不真正回答有关测试的问题。 - Bobby Jack
1
标题提到了测试,但问题细节谈论的是开发。我认为没有理由因为问题混淆就对斯图尔特进行贬低。 - David Arno
1
我认为在这里拥有数据库的副本并将其放入源代码控制中非常重要。点赞! - Jonathan Adelson
1
我甚至会添加一个本地测试环境,类似于开发测试环境。 点赞! - Schalk Versteeg
太棒了,Stewart!你的回答详尽而精彩。本地开发还有一些隐藏的好处。由于开发者环境的差异,更容易检测软件缺陷和/或设置错误。此外,它有助于拥有一个一两步部署程序,这对测试非常有利。 - Michał Niedźwiedzki
显示剩余3条评论

7

我认为在开发过程中最好拥有完全受控的本地设置,以确保其他开发人员所做的更改不会干扰你自己的工作。我已经在本地建立了开发和测试环境,因此可以执行这两个任务而无需考虑其他开发人员。我使用autotest在编码时持续运行我的测试,这意味着我可以确保我的代码是正确的并满足正确的规范。

在代码库整理好之后,我会部署到一个暂存服务器(这是尽可能接近生产环境的环境),并重新运行测试。我们还使用我们的阶段来运行负载测试和用户测试。


7

当其他人在编辑您的数据库时,保持数据库“同步”的方法之一是将您的数据库架构纳入版本控制。这并不像将源代码纳入版本控制那样简单,并且有不同的处理方式。

请阅读Coding Horror上的这篇文章:

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

这篇文章并不重要,但是它链接了K. Scott Allen撰写的六篇文章。

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


+1 强烈同意 -- 数据库架构应始终处于源代码控制下。 - Stewart Johnson
链接现在只会重定向到主页。 - Isius

6
我发现使用本地Web服务器并搭配远程数据库最好。数据库复制/同步很麻烦,所以只有在我确实需要时才会使用本地数据库。
然而,使用本地Web服务器可以消除上传页面/代码更改时的所有烦恼和缓慢。

5

本地化的优点:

  • 即使网络断开也能工作
  • 您了解机器上的每个工具

本地化的缺点:

  • 必须将所有内容同步到部署服务器
  • 如果没有版本控制,可能会覆盖其他人的工作

中心化的优点:

  • 每个人都拥有相同的工具
  • 始终在处理“真实”的内容

中心化的缺点:

  • 如果网络断开,则无法工作
  • 您“喜欢”的工具可能会缺失

我相信还有更多,但这些是我首先想到的。


“同步到部署服务器”——无论您是本地开发还是中央开发,这都应该是从源代码控制的标记版本中发布产品的一个版本,没有区别。 - Stewart Johnson
为什么我要踩这个回答?虽然这篇回答是2008年的一篇深思熟虑的评论,值得赞扬!但是,对于这位作者和其他类似回答的作者,我要表示尊重:时代已经发生了巨大变化,对于这个问题的认识也随之改变。我本想在这里详细描述,但是需要说的太多了。请看我的回答以及特别是被采纳的答案。 - Kay V
嗨@warren - 感谢您的回复。请注意,实际上我们是一致的。我对这个答案进行了负投票。当然,我的第二句话可能会引起混淆:我不想因为某人在2008年的某种想法而批评他们,因为他们很可能已经像你和我一样思考了。我邀请您也对此答案进行负投票,给被接受的答案点赞,并阅读我昨天写的答案。欢迎评论! - Kay V
@KayV - 十年前我写这个时并没有任何歧义...而且我不明白你今天怎么会看到任何歧义 :) - warren
@KayV - 我没有留下“结论”:我留下了一份利弊分析清单。给我点踩或不给都无所谓,这取决于你 :) - warren
显示剩余10条评论

5

在本地开发和测试是可以的,但是应该在反映目标环境的系统上进行质量测试,即不安装所有开发工具等。

这将有助于避免“在我的电脑上工作良好”的情况。


当然,由于标题已经修改,这个回答不再适用于问题,但是为了测试目的,它仍然有效。 - DilbertDave

4

顺便提一句,我们的设置与Matt先生所描述的类似。每个开发人员都有自己的个人沙盒,其中包含自己的Web服务器和DB。在版本发布前,版本控制的代码被拍摄/分支,并移至一个应尽可能模拟真实在线环境的暂存服务器。随后进行测试,然后将发布到生产环境。

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


3

在本地工作的另一个原因是所有内容运行速度更快。这意味着更快的开发速度。网络延迟可能会影响生产力!


1

本地开发。注意回答中的日期。不要误以为它们非常过时。

让我们澄清一下。这个问题在十年后仍然被问到,有些人继续传播过时的观念。请阅读已接受的答案。可以肯定的是,这些日子里局部开发的“缺点”在各种答案中已经得到了相当好的解决。

但是天哪! 这个问题的一些答案描述了在生产环境上进行开发,这是风险严重升级。明确指出:严格避免在生产环境上进行开发。(我相信那些开发者不再提倡这种方法。过时答案的赞同可能应该过期。也许那些投票的人会回来表明他们最新的想法。)

除了已接受的答案中提到的解决方案外,还建议使用:

  • 如果可以,请将开发工作流程容器化(例如尝试Docker)。
  • 避免从本地推送数据库到远程;在源代码控制中找到更增量、可管理的过程。Drupal 8中的配置管理倡议提供了一个有趣的例子。
  • 对于源代码控制,请考虑Git。如果您一直拖延采用源代码控制管理解决方案,现在不要再拖延了!

1

两者兼备。在开发服务器上进行一些集成和单元测试(最好与生产服务器尽可能相似,但是本地),然后在QA环境中进行一些验收测试,这应该是与您的生产服务器相同的机器或完全相同的设置(硬件,软件等)。

在数据库部分的问题上,您可以选择:

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接