5

我们一直在思考一个可以用近乎实时的数据（比如最多一周前）测试 UAT 的想法。我坚信开发和 QA 环境应该控制自己的数据，但是 UAT（生产前的最后一层）代表了一个灰色地带。所以我的问题是：

a) 这是个好主意吗？我想是的，但有一个挥之不去的怀疑。

b) 如果是这样，人们过去使用过哪些经过验证的技术？

  • 通过 SqlCompare 或类似工具手动
  • 通过脚本自动化？
  • 您如何处理 UAT/生产之间的模式变化（UAT 几乎总是领先于生产，除非在实时部署之后立即出现）？
4

2 回答 2

8

（假设 OP 打算持续、实时的模式和数据同步）

简短的回答：

  • 架构 - 否 - 在正在开发的不断发展的系统中，UAT 可能已经领先于生产，并且 UAT 将进行更改以用于未来的生产部署。
  • 数据 - 也许（为了获得好的、最新的、有代表性的数据），尽管可能需要调整任何模式差异。另一种方法是应用假数据生成器。

基本原理

通过“镜像”，我假设您不是指实时直接镜像或复制（UAT 测试通常需要设置会被覆盖的艰苦数据测试用例）。

以下是我们在企业环境 FWIW 中的做法（我们的环境是 Dev -> QA -> UAT -> Prod）

以规定的时间间隔，通常大约 1 个月的时间间隔

  • 通过 UAT 环境恢复最后一个 prod 数据库备份
  • 在恢复后刷新的每个数据库上运行环境“转换”脚本（例如，点配置，或混淆敏感的财务、客户或用户数据等）
  • 然后针对数据库运行尚未在 PROD 中的所有 UAT 脚本（您将需要良好的脚本管理更改控制纪律才能轻松跟踪这一点 - 我们仍然无法始终做到这一点）。刷新后，我们不直接比较 QA 和 UAT（即 PROD Schema），而是简单地将更改前滚回 UAT。
  • 这可以作为良好的冒烟测试/调试，因为这些相同的 vNext 脚本需要在生产发布时针对生产运行。
  • 现代系统可能不需要显式/外部版本迁移脚本（例如，实体框架代码优先迁移将尝试在第一次运行时升级数据库模式），尽管在将这些应用到遗留或共享数据库时这样做可能存在风险。

其他一些注意事项

  • 在系统相互集成的企业环境中，建议同时刷新所有系统的数据库，以便共享数据和密钥“同步”
  • 在许多公司中，UAT 环境的变化（包括数据刷新）可能需要变更控制委员会的批准，因为 UAT 可用性对于测试新系统的推出至关重要，并且可能会影响许多项目。

只是关于同步模式的“脚本”周期的注释 - 在我们的环境中：

  • DEV 对所有人都是免费的 - 任何开发主管都可以进行 DDL 或数据更改。
  • QA 和 UAT 被锁定 - 需要生成脚本（通常由 SQLCompare 生成），然后发送给 DBA 执行（在 QA 中），这些脚本在通过环境链（尤其是 UAT）提升时经过审核并获得执行批准.
  • 然后将这些脚本签入源代码控制并跟踪“每个环境”
于 2012-03-01T08:49:10.407 回答
1

这是我们为我工作的最后一家公司所做的事情。我们有许多州政府项目和合同。这是我们在某些项目中使用的环境级别的示例。在下面的示例中，QA 是为我们服务的，UAT 是为客户服务的，Pre-Prod 是我们有时创建的另一个环境，但并非总是如此；只是取决于项目。

DEV ==> QA==> UAT==> PRE-PROD ==> PROD

一旦所有数据都得到验证，我们就会从 Prod 复制到 UAT 和 QA 中的几乎所有内容，包括任何与 DB 相关的内容。

我们还有一个为某些方面编写的工具，而不必总是使用 SQL。我们有一个基于网络的程序，我不记得它是用什么写的。我们称之为 CTM - 控制表管理。在那里，我们可以在表格中滚动某些更改，例如更新、更正、下拉菜单、拼写和语法错误，实际上只是任何杂项。任何事物。有单选按钮来提交更改和框来检查您想要将更改滚动到哪些环境。

希望这对那里的任何人都有帮助或给人们一些想法。:-)

谢谢，

约翰

于 2016-08-09T19:09:39.027 回答