转向标准的“SQL数据库更改工作流程最佳实践”
背景
ASP.NET / C＃Web App MS SQL
环境 生产 UAT 测试 开发
我们创建在Mercurial中受源控制的补丁脚本（XML和sql）。我们有cmd行实用程序，可以从构建包的Release文件夹中为DB（utitlity.exe install -patch）安装补丁。补丁具有元数据，可帮助何时运行补丁，并记录安装在目标数据库中的表中的补丁。所有这些都包含在这个3岁的问题中：
SQL Server database change workflow best practices
我们的问题/扭曲
我认为这适用于表，视图，函数和存储过程。我们努力应用配置数据。以下是应用程序配置的一些接触点。
一般问题是确保我们考虑所有配置，并且在促销期间不小心不会错过任何导致悲痛的事情。
我们在一个过程中的尝试
一个。我们有QA团队的成员编写补丁（xml和sql）并检查它们。这需要一个构建来确保那些进入包。通过这种方法，它真的只是处理上面的第1项，我们在其他项目上分崩离析。好处是使它成为补丁的项目只是与实用程序一起安装。 湾开发人员在应用程序上拼凑了一个Config页面。所有配置都可以通过XML文档上传和下载，但它需要应用程序运行。对于第1项，QA团队的成员将在应用程序中手动设置配置，然后下载Config.xml文件。此XML文件将用于在其他环境中上载配置。我们将使用文本差异工具来查看来自不同环境的config.xml文件之间的差异。这涉及第1项和其他项目，但有问题。问题不是所有的配置都进入了XML文档（只需要由开发人员修复），一些配置在应用程序中没有UI，所以你仍然需要手动转到数据库上，比较XML带有文本差异的文档很难（看起来主要是由于排序，但我确定还有其他问题），XML不是非常易读，最后XML文档不允许删除现有的错误或过时的配置。 C。最近我们使用选项B，但随着时间的推移，我们刚开始手动跟踪配置并通过促销手动（UI和DB）手动推广它们。不用说很多人为错误。
所以我们一直在寻找解决方案。最终，尽可能多地实现自动化将会很棒。我正在考虑使用脚本方法，只关注流程，文档以及使用Redgate数据比较以及我们在config.xml上进行比较时所做的事情。使用Redgate我们必须创建视图，除了手动更新脚本之外，没有办法从该方法创建更新脚本。它确实至少允许在没有app运行的情况下进行比较。我也正在考虑从正常的补丁中取出配置并使其成为独立于构建的系统（utility.exe -patch -config）。当我说重点关注过程时，如果我们比较并找到客户报告的配置更改，我们仍然编写脚本，这意味着我们必须有一个流程来快速重新验证配置安装，然后再推广到下一级。至于将原始QA文档作为生动文档而不仅仅是前期文档的文档。目标是在促销期间尝试提高清晰度并减少丢失的配置。不幸的是，它没有提高交付速度。
是否有人提出任何建议或最佳做法。感谢。
答案 0 :(得分：0)
我可以确切地问一下应用程序配置的含义。我将其解释为：
完全披露我为Red Gate工作。您可能有兴趣查看Deployment Manager，它是部署应用程序，数据库和配置的部署工具。它最多可以免费使用5个项目和目标服务器。
它使用的方法是将应用程序代码和数据库状态打包到包中。这些包可以部署到开发，测试，登台和生产环境中。每个环境都部署了相同的包。
需要在环境之间更改的任何应用程序配置都通过以下方式之一进行处理：
这允许您控制应用程序配置并将它们部署到不同的环境。