多个开发人员+单一动态CRM实例+ Git - 如何克服挑战？

Question

我们是4开发人员,应该为我们的下一个CRM项目在同一个CRM实例上工作.

我们计划使用Solution Packager将解决方案文件分解为包含代表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文件.

任何有关这方面的帮助将非常感激.

Answer 1

我认为这是CRM仍然使生活变得困难的领域,并且仅提供有限的工具和支持.

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

定期(例如半夜)对源代码控制进行导出仍然是合理的,因此如果出现问题,您可以备份.

您仍然可以正常控制所有源代码,例如插件代码.

此外,您在上面提到的示例涉及开发人员从事多个CRM实例(例如,每个开发人员都有自己的CRM开发实例),而不是您提到的单个CRM实例.