转向标准的"SQL数据库更改工作流最佳实践"



转向标准的"SQL数据库更改工作流最佳实践">

背景

ASP.NET/C#Web应用程序MS-SQL-

环境生产UAT测验开发

我们在Mercurial中创建受源代码控制的补丁脚本(XML和sql)。我们有cmd行实用程序,它从构建包的Release文件夹中安装DB的补丁程序(utility.exe install–patch)。补丁程序有元数据,可以帮助确定补丁程序何时运行,我们将安装在目标数据库的表中的补丁程序记录下来。所有这些都包含在3年前的问题中:

SQL Server数据库更改工作流最佳实践

我们的问题/扭曲

我认为这适用于表、视图、函数和存储过程。我们很难处理应用程序配置数据。以下是应用程序配置的一些要点。

  1. 新客户端。BA进行系统研究和拟合分析。由此产生了一个配置词文档,说明需要设置哪些应用程序配置。请注意,随着时间的推移,其中一些可能也会分阶段出现。我们需要为开发人员和客户端UAT将这些新配置放入系统中
  2. 开发人员处理功能请求或错误修复。一个新的配置变化来自于这个变化。配置需要将其放入系统中进行测试,并升级到UAT及以上
  3. QA发现开发人员错过了相关的配置更改。该配置需要进入系统,以便升级到UAT及以上
  4. 构建转到UAT。客户端执行验收测试,但发现他们真的想更改另一个未关联的配置,并随着更改进行升级。换句话说,他们发现他们想要通过配置来更改业务流程。该配置需要将其纳入系统,以便推广到珠三角
  5. 当客户端在PRD中操作时,他们可能会调整应用程序设置。这些配置需要将其纳入系统,以便将来进行开发和测试

一般的问题是确保我们考虑了所有配置,并且在促销期间不会意外错过任何配置,这会导致悲伤。

我们对过程的尝试

a。我们让QA团队的成员编写补丁(xml和sql)并签入。这需要一个构建来确保这些补丁进入包中。通过这种方法,它确实只处理了上面的项目1,而我们在其他项目上分崩离析。好的是,对于那些将其添加到补丁程序中的项目来说,这只是一个实用程序的安装。b.开发人员在应用程序上创建了一个Config页面。所有配置都可以通过XML文档上传和下载,但这需要应用程序运行。对于项目1,QA团队的成员将在应用程序中手动设置配置,然后下载Config.xml文件。该XML文件将用于在其他环境中上载配置。我们将使用文本差异工具来查看来自不同环境的config.xml文件之间的差异。这涉及项目1和其他项目,但存在问题。问题不是所有的配置都能进入XML文档(只需要由开发人员修复),有些配置在应用程序中没有UI,所以你仍然必须手动转到一些配置的数据库,将XML文档与文本差异进行比较当时很困难(主要是由于排序,但我相信还有其他问题),XML不是很容易被人阅读,最后XML文档不允许删除现有的不正确或过时的配置。c.最近我们选择了选项B,但随着时间的推移,对于一个新客户端,我们刚刚开始手动跟踪配置,并通过升级手动升级它们(UI和DB)。不用说有很多人为错误。

因此,我们一直在寻找解决方案。最终,如果能实现尽可能多的自动化,那就太好了。除了在config.xml上使用compare之外,我正在考虑使用脚本方法,只关注流程、文档和使用Redgate数据compare。不过,使用Redgate,我们必须创建视图,除了手动更新脚本之外,没有其他方法可以用该方法创建更新脚本。它至少允许在不运行应用程序的情况下进行比较。我也在考虑从我们的普通补丁中提取配置,并使其成为一个独立于构建的系统(utility.exe–patch–config)。当我说专注于流程时,我们会比较并发现客户端是否报告了配置更改,我们仍然会编写脚本,这意味着我们必须有一个流程来快速重新验证配置安装,然后才能升级到下一个级别。至于文档,将原始QA文档作为一个活文档,而不仅仅是一个前期文档。目标是尝试提高清晰度,减少促销期间丢失的配置。不幸的是,它并没有提高交付速度。

有人有什么建议或最佳实践可以传递吗。谢谢

我能问一下你所说的应用程序配置到底是什么意思吗。我将其解释为两者:

  • web应用程序中的配置文件
  • 数据库中的静态引用数据

全面披露我为红门工作。您可能有兴趣了解一下Deployment Manager,它是一种部署应用程序、数据库和配置的部署工具。它最多可用于5个项目和目标服务器。

它使用的方法是将应用程序代码和数据库状态打包到包中。这些包可以部署到开发、测试、阶段和生产环境中。每个环境都部署了相同的包。

任何需要在不同环境之间更改的应用程序配置都可以通过以下方式之一进行处理:

  • web.config中的变量替换。该工具允许您为这些文件中的变量指定重写值,并按环境/服务器设置这些值
  • 正在按环境替换web.config文件
  • 在部署前/部署后运行的自定义powershell脚本。您可以使用这些来执行基于环境或服务器的自定义SQL
  • 数据库中的静态数据,使用SQL源代码管理的静态数据功能。我写了一篇关于如何供应的博客文章不同的静态数据集到不同的环境/客户

这允许您对应用程序配置进行源代码管理,并将其部署到不同的环境中。

最新更新