在本地机器上而不是在集中式开发服务器上进行 Web 开发的优缺点是什么?对于那些在本地机器上进行开发的人,当涉及多个开发人员时,如何为本地开发保持更新的数据库架构?
特别是,我目前正在试验用于 PHP 的 XAMPP,并且很好奇当其他开发人员定期更改数据/数据库结构时,我如何使本地计算机上的 MySQL 数据库实例保持同步。
本地开发只有在单独工作时才实用吗?
在本地机器上而不是在集中式开发服务器上进行 Web 开发的优缺点是什么?对于那些在本地机器上进行开发的人,当涉及多个开发人员时,如何为本地开发保持更新的数据库架构?
特别是,我目前正在试验用于 PHP 的 XAMPP,并且很好奇当其他开发人员定期更改数据/数据库结构时,我如何使本地计算机上的 MySQL 数据库实例保持同步。
本地开发只有在单独工作时才实用吗?
似乎有很多人喜欢拥有一个每个人都用于开发的中央服务器——我真的不明白为什么你更喜欢在一个共享环境中,人们进行更改会中断你的开发过程。
在我的商店中,每个人都有自己的开发 Web 服务器和自己的开发数据库(通常位于同一数据库服务器上,但他们自己的数据库)。这样他们就与其他开发人员完全隔离,并且不能互相打扰。
当他们实现一个特性或修复一个错误时,他们会检查他们的代码和匹配的数据库模式,以便其他开发人员可以将其作为一个完整的单元使用。发布到测试服务器或部署服务器是从源代码存储库中的标记版本完成的。
稳定而理智!我不明白为什么当开发服务器免费时你会以任何其他方式做这件事!
我认为最好有一个在开发过程中完全由您控制的本地设置,以确保其他开发人员所做的更改不会干扰您自己的更改。我在本地设置了开发和测试环境,因此我可以执行这两项任务而无需考虑其他开发人员。我在使用自动测试进行编码时不断运行测试,这意味着我可以确定我的代码是正确的并且满足正确的规范。
在代码库整理好之后,我部署到一个登台服务器(这是一个尽可能接近生产的环境),然后重新运行测试。我们还使用我们的阶段来运行负载测试并进行用户测试。
至于在其他人编辑时保持您的数据库“同步”。解决此问题的一种方法是将您的数据库模式置于版本控制之下。这不像将源代码置于版本控制之下那么简单,并且有不同的处理方式。
阅读有关编码恐怖的这篇文章:
https://blog.codinghorror.com/get-your-database-under-version-control/
与其说是帖子本身,不如说是他链接到的 K. Scott Allen 的六篇文章。
基本上,这些文章中描述的是一种基线数据库模式的方法,检查该基线的 .sql 文件,然后在每次更改模式时编写增量 .sql“更改脚本”。现在,每次开发人员签出或更新工作副本时,都会运行任何未完成的更改脚本。除非您使用为您执行此操作的框架,否则您将需要设置一些脚本/工具来自己执行此操作。
我发现使用远程数据库运行本地 Web 服务器效果最好。数据库复制/同步很痛苦,所以如果我真的需要,我只会使用本地数据库。
使用本地 Web 服务器虽然消除了在更改之间上传页面/代码的所有烦恼和缓慢。
本地的优点:
对本地的缺点:
中央的优点:
中央的缺点:
我敢肯定还有更多,但这些都是马上想到的。
在本地机器上开发和“测试”是可以的,但质量测试应该在反映目标环境的系统上执行,即没有安装所有开发工具等。
这将有助于避免“它在我的机器上运行良好”的情况。
FWIW,我会提到我们的设置就像马特先生描述的那样。每个开发人员都有自己的个人沙箱,有自己的网络服务器和数据库。在发布的边缘,版本控制的代码被快照/分支并移动到一个临时服务器,该服务器应该尽可能地模仿真实的实时环境。随后进行测试,然后发布到生产环境。
对于我自己的个人(非工作相关)项目,我在本地开发,然后进行直播。一两个项目可能在开发和公共/实时之间有一个中间测试服务器/环境。
在本地工作的另一个原因是一切都运行得更快。这转化为更快的发展。网络延迟可能是生产力杀手!
两个都。在您的开发服务器上进行一些集成和单元测试(理想情况下,它应该与您的实时服务器尽可能相似,但是是本地的),然后在 QA 环境中进行一些验收测试,这应该与您的实时服务器相同服务器,或完全相同的设置(硬件、软件等),并且应该是远程的。
当涉及到问题的数据库部分时,您可以:
在 localhost 上进行测试的一个问题是,您可能会错过链接到本地文件而不是通过浏览器访问的内容。我父亲总是在他的相机俱乐部网站上放一些链接,比如'a href="C:\My Documents\Camera Club\Photos...",而当我告诉他他搞砸了,他会说“它对我有用”。同样,在专业环境中,您可能会忘记检查源代码控制中的内容,因此它们不会部署在真实服务器上。
一种折衷的解决方案可能是拥有虚拟机,VirtualBox、VMWare 或 Parallels,这样您就可以启动虚拟 Solaris、Windows、Mac 和/或 Linux 机器来测试它——这将向您展示您的网站在默认浏览器中的外观在每一个上,再加上您可以确保事情通过非本地连接实际工作。更好的办法是拥有一个您部署到的 VM,并将其用作您的 Web 服务器进行测试。
如果您的基础操作系统是 OpenSolaris,您甚至可以使用 ZFS 并使用快照,以便在每次测试运行后将您的虚拟机回滚到其基础状态。
我一直在用 Ruby on Rails 构建一个站点,并且一直在本地进行开发,但尽可能多地部署到远程机器上。我在使用 Rails 的敏捷 Web 开发中读到,你练习部署的次数越多越好,因为当部署到生产环境时 - 不会有任何意外。
在我目前的职位上,我在自己的机器上进行开发。对于较小的项目,我只使用 Visual Studio 附带的轻量级 Web 服务器。我还在自己的机器上安装了 SQL Server 2005 和 2008,用于开发和初始测试。
总的来说,这对我来说效果很好。我遇到的一个问题是(正如其他人所指出的)保持数据库同步是一种痛苦。我最近搬到了迁移器 dot net——基本上是一个 .NET 对 Ruby on Rails 迁移的看法——用于保持本地/暂存/uat/生产数据库同步,这让我的生活压力减轻了很多。像这样的工具还可以更轻松地在团队环境中处理数据库,尽管您必须有足够的纪律才能始终如一地使用它。
我在这里的经验使我相信,本地开发结合某种数据库更改控制过程、持续集成服务器和支持合并的良好版本控制系统(我们使用 TFS)是最好的方法。这让每个人都可以做自己的事情而不会踩到其他人,但也可以确保正确合并更改。
在我之前的工作中,我们在 PC 上使用了 IIS,并结合了一个专用的开发数据库,这有点像 PITA——你必须小心不要运行任何可能会关闭数据库甚至弄乱数据的进程,因为它可能会影响其他开发人员和 IMO,这首先破坏了拥有开发数据库的目的。
我是一个人的商店;我有一个远程服务器和一个本地服务器。
我使用本地服务器进行快速原型设计和初始开发周期,我在其中进行了大量更改并需要快速测试它们。当它进入大致 alpha 阶段时,我将为项目设置一个自定义子主机并部署到我的服务器。有些特性根本无法在本地测试——即基于电子邮件的用户注册——因此这些特性在远程服务器上开发。由于它是 MINE,而不是真正的部署,因此它仍然基本上没有延迟。由于我有一个 VPS,我可以完全控制两台机器上的开发环境。
在当地发展。注意相反答案的日期。毫无疑问,它们已经过时了。
让我们澄清事实。十年后这个问题继续被问到,一些人继续发布过时的概念。阅读接受的答案。可以肯定地说,这些天是无可争议的。在过去的十年中,各种答案中提到的对当地发展的“弊端”已经得到了相当好的解决。
但是太棒了!这个问题的一些答案描述了生产上的开发,风险的严重升级。需要明确的是:严格避免在生产上开发。(我相信那些开发人员不再提倡它。对过时答案的支持可能会过期。也许那些投票的人会回来并表明他们的最新想法。)
推荐的解决方案超出了已接受答案中提到的解决方案:
对于这种情况,我总是在开发服务器上完成。因为没有重新编译。您总是可以每天获得一个新的数据库快照并将其下载到您的机器上。或者只是将 Web 服务器放在本地并将数据库指向开发框。
我发现在访问集中式开发数据库的同时使用源代码控制在本地机器上开发代码效果很好。事实证明,保持多个数据库同步是很困难的。
通常,您将拥有一个每个人都共享的本地开发服务器。