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