如何持续交付基于SQL的应用程序？

Question

我希望将持续交付的概念应用于我们正在构建的web应用程序，并想知道是否有任何解决方案来保护数据库免受意外错误提交的影响。例如，擦除整个表而不是单个记录的bug。

如何根据持续交付doctorine限制此问题的影响，其中应用程序逐渐部署在基础设施的各个部分？

有什么想法吗？

Answer 1

首先，你不能仅仅通过观察就知道什么是不好的SQL语句。您可能希望删除表的全部内容。因此，在物理上不可能有一个自动化的工具来检测意图。

因此，为了保护您的数据库，首先要确保您处于完全恢复(不是简单)模式，并且每晚进行一次完整备份，每隔15分钟左右进行一次事务日志备份。现在，无论进程中断得多么严重，您都不会丢失太多信息。您的dbas应经过培训，以便能够恢复到某个时间点。如果你没有任何dbas，我建议你可以做的最好的事情是雇佣一些dbas来保护你的数据。这在任何重要的数据库环境中都是不可商量的，如果您的数据对业务至关重要，那么如果您的数据对业务至关重要，那么没有经过培训的、经验丰富的dbas是非常危险的。

接下来，您需要像对待任何其他代码一样对待SQL，它应该在脚本的源代码控制中。如果您非常担心意外删除，那么编写删除脚本，将所有删除复制到临时表中，并且大约每周删除临时表中的内容一次。在代码评审中强制执行此约定。或者更好的做法是设置一个通过触发器运行的审计过程。审计完所有记录后，无需恢复数据库，就可以更容易地恢复150条意外删除记录。我绝不会考虑在没有审计的情况下使用任何企业应用程序。

所有SQL脚本都应该像其他代码一样进行代码审查。所有SQL脚本都应在QA上测试并通过，然后才能投入生产。这将大大降低出错的可能性。任何开发人员都不应该拥有生产环境的写权限，只有dbas才应该拥有该权限。因此，每个脚本都应该只运行，而不是一次运行一个块，因为您可能会意外忘记突出显示where子句。培训您的开发人员在脚本中正确使用事务。

Answer 2

您所关心的是发生在数据库中的坏数据。解决方案是使用所有事务的完整日志记录，以便您可以退出您想要的事务。这通常用于完整备份/增量备份/完整日志记录的上下文中。

例如，SQL Server允许您还原到某个时间点(http://msdn.microsoft.com/en-us/library/ms190982(v=sql.105).aspx)，前提是您具有完整的日志记录。

如果您正在创建和删除表，就日志所需的空间而言，这可能是一个昂贵的解决方案。但是，它可能会满足您的开发需求。

您可能会发现，对于这样的应用程序，完整日志记录的成本太高了。在这种情况下，您可能需要定期备份(每天？每小时？)把这些留着就行了。为此，我发现LightSpeed是一个用于快速高效备份的好产品。

Answer 3

通常采用的策略之一是记录增量sql语句，而不是集合模式生成，这样您就可以在更细粒度的级别上控制更改：

ex: 
change 1:
UP:
Add column
DOWN:
Remove column

change 2:
UP:
Add trigger
DOWN:
Remove trigger

一旦像这样增量地捕获更改，您就可以有一个简单但高效的脚本来从任何版本升级到任何版本，而不必担心发生的更改。当change #链接到build时，它会变得更加有效。当您部署构建时，数据库也会自动升级(向上)或降级(向下)到该特定构建。

我们在CloudMunch上有一个管道应用程序可以做到这一点。