我所使用的软件系统是医疗账单系统，大量数据和数据表以及存储过程。
我正在阅读文章“12 Steps to Better Code”，而在Joel Test＃2中指出：你能一步完成构建吗？
现在我想知道，这是否意味着部署构建（以便客户可以更新其部署）。
现在我遇到的主要问题是你如何进行一步数据库更新？
目前，当我们对数据库进行更改时，所有更改都会被记录并添加到数据库更新脚本中，该脚本会在创建部署到客户构建时附加一个版本号。
有更简单的方法吗？有些脚本或应用程序需要“之前和之后”查看数据库模式并创建像我提到的更新脚本？
或者这只是每个人都这样做的方式，我觉得很难相信，但看似合理。
自动化系统可以减少错误，并大大加快部署构建时间，我很想知道如何这样做。
答案 0 :(得分：16)
您可以经历各种复杂程度：
如果您有手动创建的更新脚本，并且只是想方便将这些脚本应用到各种服务器，请查看SSW Consulting的SSW SQL Deploy。它可以很好地处理这种情况
如果你倾向于采用更多的数据库差异方法，那么Red Gate的SQL Compare（已经提到过）和SQL Packager就是一个很棒的组合。您可以在新旧之间区分数据库，然后将更改应用于一个很好的包中 - 作为EXE或C＃项目
如果你想要一个真实的，端到端的，经过深思熟虑的方法（有一点学习曲线），请查看Innovartis' DBGhost方法。如何处理数据库开发和增量更新是一种完整的方法/技术。它非常强大，看起来非常有前途 - 但这是一种全有或全无的方法：要么你买入它并端对端地使用它，要么你没有
希望这有点帮助！
答案 1 :(得分：3)
redgate有一个工具SQL Compare来比较数据库并生成一个要同步的脚本。我们曾经使用它，但最近使用您描述的相同过程切换到手动脚本。使用具有唯一版本号的手动，细粒度脚本已经很好地完成了。
我们将升级脚本集成到单元测试中，因此它们作为持续集成的一部分与代码一起进行测试。我认为这是“一步到位”的重要组成部分。
答案 2 :(得分：2)
看一下这篇博客文章。我已经在几个项目的任何数据库版本中使用过这种类型的单一更新脚本，它运行得非常好。
http://blogs.msdn.com/danhardan/archive/2007/03/30/database-change-scripts-mambo-style.aspx
您可能需要稍微调整一下工作流程以适应您的工作流程和/或更新模板.sql文件，但总的来说，我发现这个想法是一个非常可靠的数据库部署方法。
编辑：只是详细说明我是如何使用这种技术的。基本上，我的所有数据库修订脚本都被置于源代码管理中。然后，作为构建框上的后构建步骤，在脚本目录上运行此Mambo工具，以将脚本滚动到事务所包含的单个脚本中，以便在出现任何错误时允许回滚。然后，安装程序足够智能，可以查找.sql脚本以对现有数据库运行。
这样做的原因是因为汇总的脚本会检查每个作为单个脚本的部分是否已针对所需的数据库运行。因此，只运行最新的脚本。需要注意的是，一旦脚本被检入源代码控制并已部署，您就无法编辑它，因为跟踪表已经认为脚本已经运行。这对我参与的项目来说很好，因为我们只是在脚本文件夹中添加了另一个脚本。
希望我能够很好地解释这个过程以便理解。它实际上并不复杂，如果该方法适用于您的项目，则非常有用。
答案 3 :(得分：1)
回答第一个问题“现在我想知道，这是否意味着部署构建（以便客户可以更新其部署）？”
我认为Joel Test＃2不是针对prod的部署移动，而是针对开发过程中的持续集成。
对于prod中的数据库更改，它们都应该通过脚本作为事务部署的一部分完成，或者在备份数据库之后完成。如果首次展示失败，您总是希望能够导航回来。
答案 4 :(得分：1)
将您的数据库开发为一组依赖于彼此的补丁。然后使用https://github.com/LuvDaSun/sqlpatch（由我）这样的工具构建一个用于部署的sql文件。
sqlpatch将按正确的顺序对补丁进行排序，并确保每个补丁只执行一次，即使同一个脚本运行两次也是如此。
此策略可用于在ci / cd环境中部署数据库。这使得部署就像推送到分支一样简单。
答案 5 :(得分：0)
有些应用程序会同步数据库，但我认为最好不要做你正在做的事情。编写脚本来更新数据库使您能够处理错误并运行事务。这被认为是最佳做法。
答案 6 :(得分：0)
Microsoft自己在SQL 2012中引入Data-tier applications作为部署和升级数据库的免费选项。
我使用并喜欢此工具，包括用于生产部署。