Dynamics 365/CRM 使用源代码管理解决方案组件

如果是一个大型项目,涉及比较多的开发人员,需要考虑开发环境管理、开发模式、部署管理等问题。

开发模式可以有这几种:

1.所有开发人员使用同一个开发环境(同一个组织即可)。

2.所有开发人员使用独立的开发环境(不同组织),加一个部署组织。

模式1

优点:环境管理成本低,不需要架设与管理多个开发环境;部署方便,不需要合并每个开发人员所定制的组件。

缺点:解决方案组件缺乏管理,没办法看到具体哪个开发人员修改了什么解决方案组件,哪个看出某个组件在某个时间是哪个开发人员修改过;虽然发布到测试环境是增量部署,也就是只添加需要发布的组件到部署解决方案,但是,还是谁添加到部署解决方案也不知道,从而导致出了问题找不到人,比较难发现问题原因。解决办法:可以引入一个部署环境,由专人(系统部署管理员)管理/审核需要部署到测试环境的组件。

模式2

优点:可查看/控制开发人员的修改,控制解决方案组件的修改,发布到生产安全可靠。

缺点:环境部署管理成本高,每个开发人员需要有单独的开发环境且需要从源代码下载最新解决方案组件打包并导入到本地开发环境。

 

现在很多项目都是使用第一种模式,这里说说如何使用源代码管理器来实现团队开发,先为每个开发人员部署独立的组织,SDK目录提供了一个工具叫SolutionPackager,利用该工具我们可以把解决方案包解压,解压出来可以看到很清晰的组件分类:

实体、选项集、实体关系、RIBBON、站点地图,WebResources、Role、Connect Role、Dashboard、Workflow等。

再结合源代码管理器,开发过程变为以下过程:

1.开发人员在修改前获取源代码最新组件打包导入到自己的组织,

2.把自己准备要修改的组件单独签出,

3.修改完后迁入源代码管理,

4.由部署管理员对源代码上的最终解决方案进行打包部署到部署环境

开发人员对部署环境没有权限,最终发布到测试环境、生产环境的组件可控。

不过,最终还是要项目资源、项目计划去选择开发模式。

版权声明:本文为tcli原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/tcli/p/11262961.html