问题描述
DevOps的一个目标是从源代码仓库创建可重现的、类似于生产环境的环境。为了实现这一目标，我认为还需要恢复设置环境所需的所有数据，以便可以在其中运行自动化和手动测试。
例如，我们以一个提供内容（标签、图片、富文本）给用户界面的CMS产品为例。我们希望使用来自CMS的类似于生产环境的数据对该Web应用程序进行集成测试或探索性UI测试。由于产品的性质，数据本身可以随时被用户使用CMS的UI进行操作。
这里有两个主要的用例：
1. 开发人员创建示例内容或为新功能添加所需的标签翻译。
2. 内容管理人员发布新的生产内容，其中可能包括标签翻译等静态内容。
在典型的设置中，至少有两个环境，比如staging和production。由于上述用例，存储内容的CMS数据库在这些环境之间会很快发生偏差。
如果不采取任何措施，一段时间后，这两个数据库将完全不同步，staging数据库将不再“类似于生产环境”。此外，每个新功能的发布都需要手动添加数据，如标签翻译到production数据库中，这一步骤在发布之前既没有经过验证也没有经过测试。
所以我的问题是：有什么好的方法可以将staging数据库中的新的“基线”数据带入production数据库，而不会覆盖那里的更改。还有什么好的方法可以将production中的数据带回staging环境，以提供用于测试目的的类似于生产环境的数据。理想情况下，所有这些都是自动化的，并且都是版本控制的一部分。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
根据回答1，大多数CMS都提供了将数据打包成可以检入到Git并部署到数据库的包的方式。例如，Sitecore可以使用TDS或Unicorn，其他大型CMS使用不同的工具，但基本概念相同。
这些工具允许您从数据库中选择项目，并将其序列化为代码/文本文件，然后将其打包并检入到Git中。假设您在开发工作站上有数据库的副本，您对数据库进行了一些更新，并使用TDS将更改序列化并打包到检入到开发分支的包中。
当您将开发分支部署到Staging环境时，TDS包将被应用，并对Staging环境的数据库进行相同的更新。
方案2
根据回答1，将生产数据库的更改应用到低级环境（开发/ QA，UAT）的数据库中，可以使用一个单独的流水线或按需运行的流水线来备份和恢复生产数据库，并重新创建低级环境的数据库。然后，如果有新的尚未在生产数据库中的更改，可以再次从Git应用TDS包。
方案3
根据回答1，可以使用工具将本地数据库的更改导出到磁盘，并让开发人员将更改提交到版本控制。然后，可以使用工具将版本控制中的更改应用到共享数据库中，由自动化流水线运行。
方案4
根据回答1，Sitecore和TDS中的更改始终有一个ItemID，TDS将ItemID保存在包中，您还可以在TDS中设置“Deploy Once”或“Always Deploy”属性。如果将其设置为“Always Deploy”，它将始终使用相同ID覆盖数据库中的项目。如果将其设置为“Deploy Once”，它只会在项目不存在时创建项目。
此外，还有一个时间戳，因此在开发机器上，它可以显示哪个是最后修改的，TDS（git）包中的项目还是数据库中的项目。