暂存数据库良好实践

Tom*_*Tom 35 database production staging

我即将部署到生产相当复杂的站点,并且第一次需要一个临时环境,我可以在更真实的环境中测试事物,特别是对于一些无法在本地运行的外部服务.

我的总体计划是首先在本地开发和测试,将简单的更改(小错误修复,HTML/CSS,JS等)直接推送到生产,并且对于更大的更改,首先推送到暂存子域以进行全面测试然后再进行生产.

我不认为我需要保持暂存和生产数据库同步(偶尔手动更新会这样做)但我想知道是否有关于维护与生产环境相关的暂存环境的一般良好实践,特别是涉及数据库时.

任何一般的想法/建议/经验将不胜感激.

更新:

感谢您的评论,我得到了主旨.我想值得花点时间考虑一下.接受了流行的答案.

Ste*_*ard 31

通过绕过分段并对生产进行更改是灾难和废弃的一种方法.当您进行这些更改时,minor的定义开始发生变化.其次,随着两个环境的离开(即分期不再与生产相匹配),事情就会破裂,你会对登台环境失去信心.为了从登台服务器中获得最大收益,您应该对其进行自动部署,进行全面测试,然后再部署(自动)到生产(无论变化有多小).您还应该确保完整的环境尽可能相似,并保持这种状态.这显然包括DB.我通常每天或每小时设置一次同步(取决于我建立网站或应用程序的频率)来维护数据库,并且通常会在构建过程中运行此同步.

  • +1.临时环境的整个目的是模仿将要投入生产的内容.如果生产中的更改未反映在您已暂存的代码中,那么为什么还要使用临时服务器呢? (7认同)
  • 您能否分享一些想法如何自动同步数据库? (2认同)
  • @AkshatGoel您应该已经通过备份或运行副本集来支付此费用。话虽如此,您可以使用较小的数据集,但是,您采用的每个快捷方式都是您可能在生产之前无法发现的错误。只有您可以在成本和安全性之间进行权衡。 (2认同)

Joh*_*sch 8

作为开发软件工具的人,可以帮助完成部署过程的每一步,我可以说,在临时环境中,最佳实践是精确地镜像您的生产环境.这包括相同的数据库模式(数据不相关,偶尔备份/刷新正常),相同的操作系统版本,更新的服务包,Web服务器设置等.

在理想的世界中,功能或用户验收测试不需要在分段中完成,因为分段环境的目的只是测试您的部署到生产.然而,在实际的世界中,有时您的临时环境也可以作为您的功能或UA测试环境.

每次更改生产服务器上的设置或更改配置时,都应更改登台服务器上的设置,这将确保如果您可以将应用程序部署到暂存,则很可能会毫无错误地部署到生产中.

  • 我不同意"数据不相关".根据系统的不同,生产数据可以显示您的暂存环境中的各种不可预测的问题...这有点点:) (15认同)
  • @Dolph:你的意思是"http://www.somedomain.com?id=1; CREATE TABLE unexpected_user_data"?:) ...不,我同意,用户是大量的野蛮人. (5认同)
  • @Dolph - 当我说数据时,我的意思是"订单"或"员工".如果您在数据库中存储任何类型的配置,那么您是正确的,因为它肯定需要相同.但是,如果普通数据以某种方式破坏了您的应用程序,则应该在QA测试期间捕获该应用程序.当然,如果你的登台和测试环境是相同的,那么经常刷新你的登台数据库是个好主意;) (3认同)
  • 在一个完美的世界里,我会同意.但根据我的经验,现实世界的用户总能找到生成其他人无法预期的数据的方法. (3认同)