【问题标题】:Multiple Developers + Single Dynamics CRM Instance + Git - How to overcome challenges?多个开发人员 + 单个 Dynamics CRM 实例 + Git - 如何克服挑战?
【发布时间】:2016-12-08 16:20:25
【问题描述】:

我们是 4 位开发人员,应该为我们的下一个 CRM 项目开发同一个 CRM 实例。

我们计划使用解决方案打包器将解决方案文件分解为文件夹结构,其中包含代表 CRM 解决方案每个组件的 XML 文件。

我们正在使用 Git 进行版本控制。

目前,我们预计会出现一些问题,因此我们怀疑这会增加更多开销或涉及人工干预以避免某些冲突。

在 Microsoft 网站上,它提供了一个示例,其中 CRM 解决方案文件存储在源代码管理下,但开发人员 A 和开发人员 B 都独立地对该解决方案的组件进行了更改。它说:

开发者 B 已准备好跟随开发者 A。

  1. 在提交之前,他必须获取最新的来源,以确保之前的签入不会与他的更改发生冲突。
  2. 存在冲突,因为自从他上次检索最新来源后,“活动联系人”的文件已被修改。
  3. 开发人员 B 必须协调冲突。正在使用的源代码控制系统的功能可能有助于此过程;否则以下选择都是可行的。
    • 开发人员 B 通过源代码控制历史记录(如果可用)可以看到开发人员 A 进行了先前的更改。通过直接沟通,他们可以讨论每一个变化。然后开发人员 B 只需使用商定的解决方案更新他的组织。然后,他导出、提取并覆盖冲突文件并提交。
    • 允许源代码管理覆盖他的本地文件。开发人员 B 打包解决方案并将其导入到他的组织中,然后评估视图的状态并根据需要重新定制它。接下来,他可能会导出、提取和覆盖冲突文件。
    • 如果先前的更改被认为是不必要的,则开发人员 B 允许他的文件副本覆盖源代码管理中的版本并提交。

在我看来,这似乎需要大量人工干预才能合并更改。这似乎不太理想。

想知道是否有人可以分享一些想法,让多个开发人员在单个 CRM 实例上工作的最佳实践应该是每个开发人员都应该自定义组件和插件?我们计划使用 Git 作为 ALM,并使用 Solution Packager 来分解解决方案,以便我们可以在 Git 中跟踪 XML 文件。

对此的任何帮助将不胜感激。

【问题讨论】:

    标签: git dynamics-crm microsoft-dynamics alm dynamics-crm-2016


    【解决方案1】:

    我觉得这是 CRM 仍然让生活变得困难的领域之一,并且仅提供有限的工具和支持。

    根据我的经验,每个人都可以在 CRM 中完成所有自定义和配置工作,而忘记“正常”的源代码控制是最简单和最实用的。必须导入和导出解决方案文件可能是一个非常缓慢的过程,这会让您发疯。在 CRM 之外编辑解决方案文件是您要避免的雷区。在单个 CRM 实例上工作时,不需要合并,因为每个人都可以立即看到彼此的变化。根据我的经验,这个过程通常只会增加通常可以避免的开销。

    定期(例如半夜)导出到源代码管理仍然是明智的,因此如果出现问题,您可以进行备份。

    您仍然可以正常地对所有源代码进行源代码控制,例如插件代码。

    您上面提到的示例还涉及开发多个 CRM 实例的开发人员(例如,每个开发人员都有自己的 CRM 开发实例),而不是您提到的单个 CRM 实例。

    【讨论】:

    • 谢谢詹姆斯,是的,我同意,如果我们过于频繁地导入/导出或在 CRM 外部进行定制,似乎开销大于收益。因此,我认为我们将继续采用您建议的相同方法,并将在 TFS 中导出(解决方案)作为触发午夜的构建过程。
    猜你喜欢
    • 1970-01-01
    • 2012-02-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-01-30
    • 2014-11-25
    • 1970-01-01
    相关资源
    最近更新 更多