首先，我要告诉我，我不是Microsoft Dynamics CRM专家。我只有在没有CRM或SharePoint的情况下开发.NET解决方案的经验，以及如何使用TFS的持续部署来发布自定义应用程序的一些经验。但对于当前的任务，我开始为Microsoft Dynamics CRM开发，而我并不孤单。
我们在这里与2个Scrum团队合作。两者都有自己的Microsoft Dynamics CRM 2016环境，我们使用TFS来保存我们的源代码。只有源代码，没有配置CRM。当我们发布软件时，我们需要手动将CRM配置合并到第三个环境（集成环境）中。这需要花费大量时间，所有内容都需要再次测试。
我在互联网上搜索了很多关于自定义CRM的内容，但没有找到如何与多个团队合作，并在代码中为CRM中的变化获取自动发布管道。
有谁知道开发具有多个团队的CRM解决方案的最佳实践是什么？如何制作持续发布管道以自动将C＃代码和CRM配置提供给测试，接受和生产环境？
答案 0 :(得分：1)
我所做的是使用solution packager。 Scrum团队将针对他们的CRM实例和特定解决方案进行开发。
然后他们可以（自动使用脚本和CRM API或手动）导出解决方案并将其解压缩为版本控制友好格式。
然后可以将其提交到版本控制系统，然后（使用自动构建）进行重新打包和版本化，最终作为托管包部署到集成CRM实例。
使用托管与未托管软件包虽然是一个更长的主题