一旦我们的 Web 应用程序在生产环境中使用，我们就很难通过增强或错误修复来更新它。主要原因是我们 CMS 系统设计的初始缺陷。我们通常必须花费数小时来更新每个产品环境，并且多次出现错误和长时间的调试。看起来我在抱怨，所以让我们回到讨论的客观部分。
该缺陷在于内容和编程功能如何一起存储在数据库中。所以基本上数据是如何显示的，数据本身是如何存储在数据库中的。有一些文件系统更改，但它们与内容无关。此外，应用程序本身创建了许多我们无法在数据库中跟踪的引用。
正如您所看到的，当最终用户和利益相关者使用应用程序时，我们的开发团队必须以手动方式发布生产中的更改。
另一个问题是，当数据库被修改时，应用程序会动态更改文件系统。所以我们的开发环境和生产环境现在都不同了，为了同步他们的数据，他们的数据必须去，或者开发团队必须经历很多手工工作。
我可以解释更多，甚至给你更多的例子。如果您需要，请给我评论。
自动化手工。仔细记下您需要执行的所有操作，以便将应用程序从开发环境转移到生产环境，并创建一个脚本来自动运行这些操作。例如，脚本将删除所有包含应用程序特定数据的表，然后根据应用程序的当前需求重新创建它们。
将脚本拆分为多个部分以简化测试和调试。例如，一部分可能是 shell 命令，另一部分可能是 SQL 命令。使用充足的日志记录和错误检查。使脚本成为应用程序开发过程的一部分，并将它们置于修订控制之下。
I have definitely experience similar pains in the past... Here is how I overcame them.
Split out the data that is code (that is any data in the database that is not customer data but is essential to the functioning of the app. Pull all those tables into a seperate database.
Write SQL scripts that populate that data into the database. This will allow you to recreate the skeleton of your app without relying on production data or a backup.
Take as much of the data that doesn't truly dynamically change, and put it in property files and configuration files. Flat file storage for this kind of data is ideal. Its faster to read, and doesn't have to be maintained with the database.
虽然这不会解决您的所有问题，但您可能会发现有用的是拥有一组“一键式”脚本/批处理文件，它可以刷新您的开发数据库以具有与生产相同的结构并使用一些示例数据填充它。（这是我们在上一份工作中所做的，对我们来说效果很好）
我们通过脚本以相同的方式进行所有开发、QA 和生产部署。在 QA 和生产中没有手戳过任何东西。在我们的例子中，我们使用Ant，但这只是因为它为我们提供了进行所有更改所需的功能。因此，您需要像任何其他代码一样控制构建过程并将其版本化为脚本。
听起来您也可以使用一个好的数据库比较工具。它可以帮助您生成允许您在环境之间迁移的脚本等。
如果你有 SQL Server，我听说Red Gate有很好的工具，比较工具叫做 SQL Compare。
我的观点相同，您需要弄清楚如何通过安装程序、SQL 脚本或自定义 .NET 应用程序来自动化“升级”，以操纵数据库和“升级”。
此外，您可能对Liquibase感兴趣。它是一个开源工具，用于跟踪数据库数据和模式更改，并且可以轻松地应用您在生产环境中对开发数据库执行的重构。它是独立的 DBMS（供应商）。我还建议自动执行升级产品部署的步骤，如前所述。