问题描述
想要了解是否有一种好的DevOps方法来构建产品的演示数据工作流程。由于应用程序不断变化，这种情况变得困难。有几种情况需要考虑：
1. 旧的演示数据在新版本中变得过时，或者可以认为旧数据在新版本中已损坏。
2. 引入了新的业务逻辑，需要与应用程序进行交互才能形成新数据。您不能根据新模式、静态规则或旧数据来推导/填充此类数据。
3. 项目经理掌握演示数据应该如何展示，而不是工程师。因此，工作流程需要在过程中进行匹配，从（构建->测试->部署）某种方式。
一种方法是运行包含演示数据的测试。因此，在运行测试之后，我们可以提取用于演示的数据。但是，我可以看到测试可能会非常耗时，并且不像导入csv文件那样即时。此外，项目经理和工程师之间的协调似乎紧密耦合。
另一种方法是从存储库中的新模式开始，并从那里生成数据。但是，这需要创建生成规则的开销，这些规则可能与应用程序本身的逻辑不同步。
似乎自上而下的方法更好，因此您可以每个发布生成动态数据集。而不是使用旧的静态数据以向后兼容的方式工作。
问题是在每次迭代中保持应用程序和数据同步和有效，同时允许项目经理和工程师相互独立地工作，而不依赖于彼此。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
将数据管理和数据集操作作为独立的资产是否可行？数据已经变得更加重要，因此更加以数据为中心的方法可能会有所帮助。
这也证明了组织内部的信息孤岛和沟通不畅：即使在DevOps之前，在敏捷团队（例如Scrum）中，您不仅可以有工程师，还可以有产品负责人和测试人员，他们负责为团队提供有用的测试和有用的测试数据。
也就是说，第四种可能的情况是您从生产中获取数据集并进行混淆/匿名化。如果数据集太大，您需要将其减少为代表性的混合。在这些步骤被充分理解后，以DevOps的方式自动化所有这些步骤将是最好的方法。=> 实际工作场景。
虽然有一些法律变通方法，但这需要额外的努力：
– 数据混淆
– 数据匿名化
– 合成数据
根据您的领域，可能还有适用且更灵活的企业级工具用于主数据管理，其中产品负责人可以管理和版本化各种数据配置文件。
由于DevOps方法不仅仅是找到一个工具来使用，还包括进行实验以了解更多信息，以下是关于这些主题的最新学术研究的示例。
一个示例研究：《超越模糊：数据匿名化的组织方法》（Hargitai等，2018年）
另一个示例：《使用合成和真实数据的机器学习：不同医疗保健数据集和不同算法的评估指标的相似性》（Heyburn等，2018年）
方案2
是否可能根据功能的成熟度/稳定性将数据分隔开？与API版本控制相同的方法在这里可能非常有效。
从概念上讲，这意味着可以通过底层数据存储的快照将“稳定”功能的数据从构建到构建复制（根据上下文可能会有一些修改）。
对于“预览”（不稳定，正在开发中）功能的数据最好生成-这样无论功能如何更改，始终可以获得产品的最新视图。生成可以在应用程序中进行（例如，在UI中自动填充，甚至可以使其看起来整洁）。
一旦“预览”功能升级为“稳定”，其数据可以包含在快照中（作为附加的发布过程步骤）。
最好与工程师对新功能生成数据的常见方式进行对齐，然后将其数据生成器与代码一起交付。
这种混合方法可以实现以下好处：
– 设置和对齐DevOps、工程和产品关于如何获取测试数据的期望
– 无需处理生成整个数据集所需的时间的指数增长
– 实现正在开发的功能的快速迭代
– 教育开发人员并使他们更加了解DevOps（他们必须在开始开发功能时获取最后一个稳定数据快照并在其开发环境中部署它）
– 各方之间实现快速反馈循环，从而提高产品质量（如果快照无法部署或应用程序崩溃，则发布过程出现问题）
这种方法没有太多的缺点，但我要强调一些最重要的缺点：
– 它需要工作。这种方法的主要目的是修复（或实际上定义）流程，因此需要额外的努力来权衡、解释、原型和构建对齐。
– 它不会解决预览功能中的依赖性问题，例如，如果功能B依赖于A，并且它们都在开发中，那么必须生成两者的数据，并且在B之前必须稳定A。
总的来说，您正在处理的问题并不容易，如果您能分享您的经验，以及您的项目采取的路径和背后的原因，我将不胜感激。祝好！