合并 2 个 CRM 2011 非托管解决方案

发布于 2024-12-10 21:02:08 字数 166 浏览 0 评论 0原文

我们正在与另一家咨询公司合作开展一个项目。大多数情况下,我们每个人都有自己的领域,但也有一些交叉。

假设我们都修改了一个具有冲突更改的实体。使用“最后一个获胜”规则,无论最后导入的解决方案都将实施其更改。

是否有工具或某些已知的方法可以在导入完成之前识别这些冲突,以帮助我们解决此问题?

We are working a project jointly with another consulting firm. For the most part we each have our own domains, but there is a little crossover.

Let's say we both modify an entity that has conflicting changes. Using the "last one in wins" rule, whichever solution is imported last will have its change implemented.

Is there a tool or some known methodology for identifying these conflicts before the import is done to help us manage this problem?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

魂牵梦绕锁你心扉 2024-12-17 21:02:08

我已经多次遇到这种情况,我的方法是导出自定义项并使用 WinDiff 或 BeyondCompare 等代码比较工具检查自定义文件(xml 文件)的内容。

I have run into this numerous times and my approach has been to export the customizations and inspect the contents of the customizations files (xml files) with a code comparison tool like, WinDiff or BeyondCompare.

蒲公英的约定 2024-12-17 21:02:08

严格来说,这并不是“最后一个获胜”的情况,有一个模型可以允许某些共存,例如,如果您都将字段添加到同一表单中。

需要记住的一件事是,您应该在链接到唯一发布者的非托管解决方案中进行所有自定义,并且该发布者应该具有唯一的前缀,因此您可以使用 John_ 作为所有新实体、字段等的前缀,另一家公司可能会使用 Acme_ 或任何适合他们的东西。

这有助于减少直接冲突,例如都添加具有相同名称但不同类型的字段(由于前缀不同,它们不会具有相同的架构名称)

It's not strictly a "last one wins" scenario, there is a model to allow some coexistence, eg if you both add fields to the same form.

One thing to bear in mind is that you should both be doing all your customisations in an unmanaged solution linked to a unique publisher and that publisher should have a unique prefix, so you might use John_ for the prefix for all new entities, fields etc, and the other firm might use Acme_ or whatever suits them.

This helps to reduce direct conflicts such as both adding a field with the same name but different types (they won't have the same schema name, because of the different prefices)

温柔戏命师 2024-12-17 21:02:08

将表单组件保留在单独的选项卡和部分中,如果您都使用托管解决方案,则表单自定义将被合并。同样,站点地图和功能区自定义都可以独立开发,如果您将更改分组在一起,您可以让 CRM 为您合并解决方案。

不要将其他咨询公司的主要定制解决方案导入您的开发环境,以避免在它们之间创建交叉依赖关系,但是您可以引用相同的实体。如果两家咨询公司所需的某些实体都是定制的,您需要预先就“核心”解决方案中应包含的内容达成一致;作为先决条件,在所有开发环境中开发、共享和安装它。

根据项目的复杂性,您可能会发现使用共享解决方案托管 IFD 临时环境,两家公司都可以使用该解决方案来解决冲突并用作测试环境。

预先同意如何投诉和处理应报告、调查和处理 UAT 问题预先解决并明确工作分工。

Keep your form components in separate tabs and sections, if you both use managed solutions the form customisations will be merged. Similarly SiteMap & Ribbon customisations can both be developed independently if you keep your changes grouped together you can let CRM merge the solutions for you.

Do not import the other consultancies main customisations solutions into your development environment to avoid creating cross-dependancies between them, you may reference the same entities however. If some entities needed by both consultancies are custom, you will need to agree on what should be included in a "core" solution upfront; develop, share and install it on all development environments as a pre-requisite.

Depending on the projects complexity, you may find that hosting an IFD staging environment with a shared solution which both companies can use to resolve conflicts and to serve as a testing environment useful.

Agree upfront how complaints & UAT issues should be reported, investigated & resolved and clearly define the division of work upfront.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文