微策略工作流程的最佳实践
Best practices for a microstrategy workflow
我们是一个 5 人的团队，从事微观战略工作。我们共享每个角色，但我们没有工作流。
每个人都可以构建或更改属性并更改模式。这通常会导致报告无法正常工作。此外，没有 "good" 文档。我们尝试用sharepoint建立一个文档，但是我们也没有工作流程。
最初，我们有一个旧项目，其中每个报告的所有属性都是新构建的。所以我们没有重用任何现有的模式对象。
因此，我们开始了一个新项目。我们意识到，由于缺乏理解和缺乏工作流程，我们犯了很多错误。我们觉得我们慢慢理解事情（亲子），但工作流程仍然很糟糕。
我们有一个开发项目和一个虱子项目，但是按照我们现在的工作方式，我们遇到了很多问题。特别是，缺少的版本控制系统正在杀死我们。我们执行更改并忘记我们所做的。因此，我们必须使用备份，在给定的一天破坏有用的工作
那么什么是最佳实践：
* 部署新属性、事实和报告
* 确保旧报告在构建新属性和事实后仍然有效
* 改进文档
* 在事实表和父子关系上定义的属性
感谢任何帮助
在团队环境中进行 MicroStrategy 开发，从开发部署到上线，可能非常具有挑战性。正如您正确指出的那样，缺乏版本控制和对象之间未知的相互依赖性可能会导致无法描述的问题。这个问题没有唯一的正确答案，但我建议如下：
使用 MicroStrategy 提供的所有工具。当您从一个项目部署到另一个项目时，不要只是在对象管理器中拖放，而是创建一个包。当您部署该包时，请确保您选择创建一个撤消包，这样您可以在遇到任何问题时回滚更改。
关于这一点，请尝试提前发现这些问题。 运行 Integrity Manager 在部署前后，即使只是为报告生成 SQL，也会指出您是否破坏了任何东西。关于这一点：
创建第三个 environment/project。将此 test/release 控件命名为任何你喜欢的。在这里您可以测试在对象管理器中创建的包，以确保它们具有预期的效果，并且不会破坏任何东西。实际上，这是一个干燥的 运行 让您的部署生效。这个环境应该定期从实时刷新（通过项目复制），以确保它不会进入意外状态（例如，由于对象管理器包导入损坏）。
除此之外，我只能提供组织建议。一个人负责模式对象（即事实、属性、转换）的情况并不少见，这样开发人员就不会撤消彼此的更改。如果你有一个大项目，这些对象可以分成功能区域，并分配给个人。
文档总是很棘手，但我喜欢尽可能多地放入对象描述中。这具有在 Web 界面中可见（通过工具提示）的优势，并且包含在自动化项目文档中，如果您选择生成它的话。显然每个对象都有更改日志功能，但根据我的经验，这些日志很快就不会被开发人员完成，因为保存发生得太频繁了。尽管如此，如果您能让人们填充它，您就会在了解项目中的变化方面抢占先机。
总结一下：
- 使用对象管理器包来部署更改
- 使用 Integrity Manager 测试更改，以尽早发现任何问题
- 使用发布控制 project/environment，这样您就不会在生产环境中发现问题
- 尽可能将模式对象的责任分配给特定的人。
我们是一个 5 人的团队，从事微观战略工作。我们共享每个角色，但我们没有工作流。
每个人都可以构建或更改属性并更改模式。这通常会导致报告无法正常工作。此外，没有 "good" 文档。我们尝试用sharepoint建立一个文档，但是我们也没有工作流程。
最初，我们有一个旧项目，其中每个报告的所有属性都是新构建的。所以我们没有重用任何现有的模式对象。
因此，我们开始了一个新项目。我们意识到，由于缺乏理解和缺乏工作流程，我们犯了很多错误。我们觉得我们慢慢理解事情（亲子），但工作流程仍然很糟糕。
我们有一个开发项目和一个虱子项目，但是按照我们现在的工作方式，我们遇到了很多问题。特别是，缺少的版本控制系统正在杀死我们。我们执行更改并忘记我们所做的。因此，我们必须使用备份，在给定的一天破坏有用的工作
那么什么是最佳实践： * 部署新属性、事实和报告 * 确保旧报告在构建新属性和事实后仍然有效 * 改进文档 * 在事实表和父子关系上定义的属性
感谢任何帮助
在团队环境中进行 MicroStrategy 开发，从开发部署到上线，可能非常具有挑战性。正如您正确指出的那样，缺乏版本控制和对象之间未知的相互依赖性可能会导致无法描述的问题。这个问题没有唯一的正确答案，但我建议如下：
使用 MicroStrategy 提供的所有工具。当您从一个项目部署到另一个项目时，不要只是在对象管理器中拖放，而是创建一个包。当您部署该包时，请确保您选择创建一个撤消包，这样您可以在遇到任何问题时回滚更改。
关于这一点，请尝试提前发现这些问题。 运行 Integrity Manager 在部署前后，即使只是为报告生成 SQL，也会指出您是否破坏了任何东西。关于这一点：
创建第三个 environment/project。将此 test/release 控件命名为任何你喜欢的。在这里您可以测试在对象管理器中创建的包，以确保它们具有预期的效果，并且不会破坏任何东西。实际上，这是一个干燥的 运行 让您的部署生效。这个环境应该定期从实时刷新（通过项目复制），以确保它不会进入意外状态（例如，由于对象管理器包导入损坏）。
除此之外，我只能提供组织建议。一个人负责模式对象（即事实、属性、转换）的情况并不少见，这样开发人员就不会撤消彼此的更改。如果你有一个大项目，这些对象可以分成功能区域，并分配给个人。
文档总是很棘手，但我喜欢尽可能多地放入对象描述中。这具有在 Web 界面中可见（通过工具提示）的优势，并且包含在自动化项目文档中，如果您选择生成它的话。显然每个对象都有更改日志功能，但根据我的经验，这些日志很快就不会被开发人员完成，因为保存发生得太频繁了。尽管如此，如果您能让人们填充它，您就会在了解项目中的变化方面抢占先机。
总结一下：
- 使用对象管理器包来部署更改
- 使用 Integrity Manager 测试更改，以尽早发现任何问题
- 使用发布控制 project/environment，这样您就不会在生产环境中发现问题
- 尽可能将模式对象的责任分配给特定的人。