组织 Dynamics 365 CRM 工作流/插件/程序集的存储库结构的最佳实践
设置CRM（Dynamics 365）项目的存储库结构的最佳方法是什么，该项目应包含由工作流活动/插件代码实现的高级功能？
拥有一个用于整个解决方案的存储库和内部的存储库是否明智，每个实体都应该包含工作流活动或插件的单独项目？
要考虑的好点：
- 的构建调试/发布程序集（.dll）
- 通过插件注册工具更新工作流程/插件
- 管道可维护性的任何限制
- 这些工作流程活动/插件的
What would be optimal way to set up repository structure for CRM (Dynamics 365) project that should contain advanced features that are being implemented by Workflow Activity/Plugin code?
Would it be wise to have one repository for whole solution and inside, there would be separate projects for each Entity that should contain Workflow Activity or Plugin?
Good points to consider:
- Building debug/release assemblies (.dll)
- Updating Workflow Activity/Plugin via Plugin Registration Tool
- Any limitations for pipelines
- Maintainability of these Workflow Activities / Plugins
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们管理存储库的方式随着工具的发展而变化，并且很大程度上取决于个人喜好。
我的方法是将与 Dynamics/Power Platform 相关的所有内容存储在单个 GIT 存储库中，并专注于根据 Power Platform 解决方案对项目进行分组。
然后，我们通常有另一个根文件夹来存储通用 DevOps 脚本
例如：
The way we manage our repositories changes as the tooling evolves, and is highly dependent on personal preference.
My approach is to store everything related to Dynamics/Power Platform in a single GIT repository, and focus on grouping items based on Power Platform solutions.
We usually then have another root folder to store the generic DevOps scripts
For example: