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

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

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

在我的商店里,每个人都有自己的开发Web服务器和自己的开发数据库(通常放在同一个数据库上 服务器 但是他们自己的数据库)。这样,它们就完全与其他开发人员隔离了,并且不能互相干扰。

当他们实现一个特性或修复一个错误时,他们会签入他们的代码。 以及匹配的数据库模式 这样它就可以作为一个完整的单元提供给其他开发人员。对测试服务器或部署服务器的发布是从源代码存储库中标记的版本完成的。

稳定和理智!我不明白为什么当开发服务器是免费的时,你会以任何其他方式来做这件事!

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

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

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

阅读这篇关于恐怖编码的文章:

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

与其说这篇文章本身,倒不如说是他所链接到的6篇文章。

基本上,这些文章中描述的是一种将数据库模式作为基线的方法,检入该基线的.sql文件,然后在每次更改模式时编写incremental.sql“change scripts”。现在,每当开发人员签出或更新工作副本时,任何未完成的更改脚本都将运行。您需要自己设置一些脚本/工具来实现这一点,除非您使用一个为您实现这一点的框架。

我发现使用远程数据库运行本地Web服务器效果最好。数据库复制/同步是一个难题,所以如果我 真的? 不得不。

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

当地的优点:

• 即使网络中断也能正常工作
• 你知道机器上所有的工具

当地的缺点:

• 必须将所有内容同步到部署服务器
• 没有版本控制,你就可以干掉别人的工作。

专业人员到中心:

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

到中央的缺点:

• 网络断开时无法工作
• 您的“最爱”工具可能丢失

我相信还有更多,但这些马上就会浮现在我的脑海中。

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

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

我要说的是,我们的设置就像马特先生描述的那样。每个开发人员都有自己的个人沙箱来处理,有自己的Web服务器和数据库。在发布的边缘,版本控制的代码是快照/分支的,并移动到一个临时服务器,该服务器应该尽可能地模拟真实的实时环境。测试接着进行,然后发布到生产环境中。

对于我自己的个人(与工作无关)项目,我在本地开发,然后推送现场。一个或两个项目可能在开发和public/live之间有一个中介测试服务器/环境。

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

在本地主机上测试的一个问题是,您可能会错过链接到本地文件的内容,而不是通过浏览器访问的内容。我父亲总是在他的相机俱乐部网站上添加链接,这些链接类似于“a href=“c:\my documents\camera club\photos…”,当我告诉他他已经成功了,他会说“这对我有用”。同样,在专业环境中,您可能会忘记签入源代码控制,因此它们不会部署在真正的服务器上。

一个折衷的解决方案可能是让虚拟机(virtual box、vmware或parallel)启动,这样您就可以启动虚拟Solaris、Windows、Mac和/或Linux设备来测试它——这将向您展示您的站点在每个默认浏览器中的外观,而且您还可以确保通过非本地连接实际工作。更好的方法可能是部署一个虚拟机,并将其用作测试的Web服务器。

如果您的基本操作系统是OpenSolaris,那么您甚至可以使用ZFS和快照,以便在每次测试运行后将虚拟机回滚到其基本状态。

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

当涉及到问题的数据库部分时,您可以:

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

我一直在RubyonRails中构建一个站点,我一直在本地进行开发,但尽可能频繁地部署到远程机器上。我在《Rails的敏捷Web开发》中读到,您越练习部署,效果越好,因为在部署到生产环境时,不会有什么意外。

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

总的来说,这对我很有效;我遇到的一个问题是(正如其他人所指出的)保持数据库同步是一种痛苦。我最近搬到 migrator dot net --基本上.NET采用了RubyonRails迁移——为了保持本地/Staging/UAT/Production数据库的同步,它使我的生活压力大大降低。这样的工具也可以使在团队环境中处理数据库更加容易,尽管您必须有足够的纪律来一致地使用它。

我在这里的经验使我确信,本地开发与某种DB变更控制过程、持续集成服务器和支持合并(我们使用TFS)的良好版本控制系统相结合是最好的方法。这样,每个人都可以在不影响其他人的情况下做自己的事情,但也可以确保正确地合并更改。

在我之前的工作中,我们在个人电脑上使用了IIS,再加上一个专用的开发数据库,这有点像pita——你必须小心不要运行任何可能会破坏数据库甚至弄乱数据的进程,因为这可能会影响到其他开发人员,而imo,这种做法破坏了在fir中使用开发数据库的目的。圣地。

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

我使用本地服务器进行快速原型设计和初始开发周期,在那里我进行了大量的更改,需要快速测试它们。当它到达一个大致的alpha阶段时,我将为项目设置一个定制的子主机并部署到我的服务器上。有些特性不能在本地进行测试,例如基于电子邮件的用户注册,因此这些特性是在远程服务器上开发的。因为它是我的,而不是真正的部署,所以它仍然基本上没有延迟。因为我有一个VPS,所以我可以完全控制这两台机器上的开发环境。

对于这样的情况,我总是在开发服务器上完成。因为没有重新编译。你可以每天都得到一个新的数据库快照,然后把它放到你的机器上。或者让Web服务器本地并将数据库指向dev框。

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

通常,您会有一个每个人共享的本地开发服务器。

在当地发展。把日期记在相反的答案上。别误会他们已经过时了。

让我们把记录整理一下。十年后,这个问题仍在被问到,一些人继续传播过时的观念。阅读接受的答案。可以肯定地说,这是无可争辩的。在随后的十年里,各种答案中提到的地方发展的“弊端”已经得到了合理的解决。

但是 伊克斯! 这个问题的一些答案描述了在生产上的发展,风险的严重升级。明确:严格避免在生产中发展。(我相信那些开发人员不再鼓吹它了。过时答案的赞成票可能会过期。也许那些投票的人会回来表明他们的最新想法。)

除了接受答案中提到的建议解决方案:

• 如果可以,将您的开发工作流装箱(例如,尝试Docker)。
• 避免将数据库从本地推送到远程;在源代码管理中找到一个更加增量的、基于管理的过程。这个 configuration management initiative in Drupal 8 提供了一个有趣的例子。
• 对于源代码管理,考虑Git。如果您推迟采用源代码管理解决方案,就不要再拖延了!