Dynamics CRM中2011：托管解决方案或从DEV到珠三角

Question

部署的更改的动态CRM 2011，微软建议通过包装变化管理（或托管）解决方案从开发移动实体的自定义珠三角。非托管是不好的，因为您无法在需要时删除实体（删除解决方案只会删除容器，解决方案中包含的实体仍然存在）。在培训期间的大多数实验示例中，您将自定义系统，然后将自定义实体作为托管解决方案导出，然后将其导入生产。这种基于解决方案的方法是干净的，可以更容易地控制PRD中的内容，将相关实体捆绑在一起，跟踪依赖关系等，所以我明白了。

有很多次，但是，当你需要转储DEV服务器上的组织，并从珠三角恢复（用于解决特定的数据问题或其他原因）。我们通过禁用然后删除DEV组织，然后要求DBA团队从生产中恢复CRM数据库来完成此操作，然后将组织导入DEV服务器。但是，如果我们实施这种基于“托管解决方案”的变更迁移流程，在我们转储DEV并从珠三角重新创建它之后，我们不会失去改变实体的能力吗？这些解决方案都处于只读模式？如果我们在这些托管解决方案中启用定制，我们是否能够向解决方案中添加新实体或从解决方案中删除实体而不删除整个解决方案？因为我认为托管解决方案被视为一个单一的代码单元，所以它要么删除全部，要么全部删除。有兴趣了解其他人如何解决此问题。我们已经处理了这个

Answer 1

一种方法是使用我们用它来管理配置的“配置主节点”一个单独的清洁开发机。该机器不用于任何其他开发或测试工作。 plugsin等开发机器可以从prod重建，但是这台机器仍然是所有解决方案的主人。不是一个理想的解决方案，但它确实避免了能够将托管解决方案转换为非托管（可能通过某些密码设施）的“功能差距”

Answer 2

我建议不要在这些类型的dev-to-testing-刺激的情况。

如果你不确定这个尝试在你的开发环境中删除实体并发布变更到生产环境。

解决方案是包容性的，这意味着CRM不会删除解决方案中删除的字段和实体。

的唯一方法删除实体是卸载，因此您的解决方案中删除您的解决方案覆盖所有实体的生产数据！

虽然理论上解决方案看起来很完美，但它们仅适用于第三方供应商。

通过卸载解决方案可以回滚的beeing的目标是一个梦想。考虑涉及数据转换的数据模型更新。没有魔术功能会扭转这种情况。

这是一个更简单和可靠的恢复备份。