我之前曾在博客中介绍了向Microsoft 报告新想法，问题和错误的重要性，以及社区为何会从共享中获益。我经常遇到经验丰富的工程师经常提供解决方案，并且非常愿意免费提供，以便将修复后的代码纳入标准解决方案。

但是，正式的支持路径确实需要时间和精力，并且请记住并非所有Microsoft支持顾问都是可以与之讨论X ++主题的工程师。但是，如何更容易为D365社区做出贡献？ 但是您知道Microsoft有一个使用Dynamics 365 F＆O的社区驱动工程计划吗？这不仅包括错误，还包括新功能。社区驱动工程（CDE）是微软努力使外部工程师更有效地提供推荐的错误修复作为Microsoft的次要功能，以及使Microsoft更有效地接受来自社区的修复。如果修复程序被接受，它将合并到主要的Dynamics 365 F＆O分支中。我已经尝试了该程序，并在自动报告的修复程序中报告已完成，并且修复程序已被接受，并且希望在不久的将来整个社区都可以从中受益。

怎么开始？

如果您拥有合适的技能并愿意分享和赠送您的修复程序（或功能），请访问https://aka.ms/Communitydrivenengineering。您需要被接受加入该计划，并且您的用户必须先列入白名单才能访问。CDE还有一个私人Yammer组，您可以在接受时访问。但我必须警告你。该计划适用于我们社区中最有经验和技术人员，深入X ++和AzureDevOps。您必须获得组织中CxO级别的批准才能与Microsoft共享代码。（律师的东西）以下是外部工程师的总体流程：

您在CDE Azure DevOps中创建了一个错误或功能
错误或功能由MS团队审核并接受或拒绝
您为此工作创建一个分支并在此分支中提交
完成后，您将创建一个Pull Request
拉动请求由MS团队审核并提供反馈
经过一些迭代后，Pull Request将被批准并完成
MS团队将接管代码并包含在将来的版本中

以下是有关其工作原理的更多技术细节。

以下文本是从CDE的入职文档中复制的。开始使用CDE大约需要一个小时，其中大部分是初始构建时间。

使用内部版本8.1.195.20001（app 8.1，平台更新22）或更高版本从LCS获取开发VM。我可以访问的最新分支是10.0.80.19，基本上是10.0.2 PU 26。
确保已在VM上至少打开一次Visual Studio以登录并选择默认设置。
从https://git-scm.com/downloads在机器上安装Git 。默认安装选项应该可以正常工作。
从管理员命令行实例，将此repo克隆到计算机上的某个位置。 pushd k：\ mkdir git cd git git clone https://dev.azure.com/msdyncde/_git/cde
在Git git config -global user.name中定义您的用户名和电子邮件“John Doe” git config -global user.email johndoe@example.com
将git repo挂载到F＆O部署 pushd K：\ git \ cde powershell。\ Mount.ps1
以管理员身份打开Visual Studio并重建以下模型 ApplicationSuite ApplicationWorkspaces FiscalBooks GeneralLedger 项目零售税

此时您可以开始开发（实际上在SYS层中）

如何提交更改？

社区提交的更改将提交到与开发虚拟机上的版本匹配的相同REL分支。一旦拉取请求（PR）完成，就表示微软已经正式接受了更改，它将在未来的正式版本中显示，通常是下一个月的版本（取决于发布关闭的月份中的哪一天）。此更改将仅通过将来的正式版本进入msdyncde的主分支。同步到REL分支的提示将引入从该版本提交的其他社区更改。

根据更改是否与现有代码的错误行为或新行为相关，创建错误或功能。 https://dev.azure.com/msdyncde/cde/_workitems新工作项> bug 填写标题，将其分配给自己，并将区域设置为您对行为所属位置的最佳猜测（将帮助我们适当地进行审核））在repro步骤和系统信息中，提供有关为何需要进行此更改的信息
在Git中，创建一个要处理的主题分支。分支通常以用户名/错误号命名。 git checkout -b johndoe / 482 git push -set-upstream origin johndoe / 482
在Visual Studio中，正常更改Application Suite SYS代码。实际上是在Git文件夹中直接进行更改。
将更改推送到VSTS。 git add -A git commit -m“消息解释正在改变的内容” git push
从VSTS发送拉取请求 https://dev.azure.com/msdyncde/_git/cde/pullrequests?_a=mine新拉取请求源分支= johndoe / 482，目标分支= Rel_8.0.30.8022（或任何版本的你有）填写标题和说明，链接工作项>创建

Microsoft审阅者（或其他社区审核人员）的任何反馈都将显示在PR中。可以通过在Visual Studio中编辑并再次执行git add / commit / push来对PR进行更改。Microsoft签署后，所有注释都已解决，工作项已链接，并且所有其他策略都已满足，然后您可以单击“ 完成” 以完成拉取请求。公关完成后，微软正式接受该变更将成为未来正式发布的一部分，通常是下一个月发布。

在幕后

powershell脚本首先通过检查K：\ AosService \ PackagesLocalDirectory \ ApplicationSuite \ Descriptor \ Foundation.xml 文件来检查VM上存在的源代码版本。
然后它检查与该版本相关联的REL分支，该分支与当前在该机器上的平台和其他模型版本匹配。
更新开发配置文件以允许更改SYS模型，这通常在开发虚拟机上不允许。

除了采用加速方法将修复程序纳入主分支之外，参与者还可以获得更多好处。您可以通过Microsoft提供的所有代码分支访问最新和最好的代码更改。您可以搜索代码，查看是否存在影响您安装的本地扩展或代码的代码更改。您还可以了解Microsoft代码如何发展以及标准应用程序中是否提供了改进。您还将为世界上最好的开发人员建立逐渐非常有价值的网络，在那里您将与实际人员讨论技术主题，从而创建世界上最好的ERP系统。那些考虑进入这个项目的人最后开个玩笑：Git和性别很相似。两者都涉及很多承诺，推动和拉动。只是不要git push -force I have previously blogged about the importance of reporting new ideas, issues and bugs to Microsoft, and also why the community will benefit from sharing. I have often experienced that experienced engineers often have the solution available and are more than willing to give it for free to get the fixed-up code into the standard solution.

But the formalized support path does require time and energy and remember that not all Microsoft support consultants are engineers that you can discuss X++ topics with. But how can the process of contributing to the D365 community be easier? But did you know that Microsoft have a program for Community Driven Engineering with Dynamics 365 F&O? This covers not only bugs, but also new features. Community driven engineering (CDE) is a Microsoft effort to make external engineers more efficient at providing recommended bug fixes as minor features to Microsoft, as well as to make Microsoft more efficient in accepting fixes from the community. If the fix is accepted, it will be merged into the main Dynamics 365 F&O branch. I have tried the program, and reported in a fix for auto-report as finished, and the fix was accepted, and hopefully in the near future the entire community can benefit from it.

How to start?

If you have the right skills and the willingness to share and give away your fixes (or features) you can sign up at https://aka.ms/Communitydrivenengineering. You need to be accepted into the program, and your user must be whitelisted before you can access. The CDE also have a private Yammer group, that you get access to when accepted. But I must warn you. This program is meant for the most experienced and technical people we have in our community, and that are deep into X++ and AzureDevOps. You must have approval from CxO-level in your organization that you can share code with Microsoft. (Lawyer stuff) Here is the overall flow for the external engineer:

You create a bug or a Feature in CDE Azure DevOps
The bug or Feature is reviewed by the MS team and accepted or rejected
You create a branch for this work and commit in this branch
When done you create a Pull Request
The Pull Request is reviewed by the MS team and feedback is provided
After some iterations the Pull Request will be approved and complete
The MS team will take over the code and include in a future release

Here are the more technical details of how it works.

The following text is copied from the onboarding documentation of the CDE. It takes approximately one hour to get started with CDE, the majority of which is the initial build time.

Obtain a development VM from LCS with build 8.1.195.20001 (app 8.1, platform update 22) or later. The latest branch I have access to is 10.0.80.19, that basically is 10.0.2 PU 26.
Make sure you have opened Visual Studio at least once on the VM to sign in and pick default settings.
Install Git on the machine from https://git-scm.com/downloads . The default installation options should work fine.
From an administrator command line instance, clone this repo to a location on the machine. pushd k:\ mkdir git cd git git clone https://dev.azure.com/msdyncde/_git/cde
Define your user name and email in Git git config –global user.name “John Doe” git config –global user.email johndoe@example.com
Mount the git repo into the F&O deployment pushd K:\git\cde powershell .\Mount.ps1
Open Visual Studio as administrator and rebuild the following models ApplicationSuite ApplicationWorkspaces FiscalBooks GeneralLedger Project Retail Tax

At this point you can start development(in the SYS layer actually)

How to submit a change?

Changes submitted by the community are committed to the same REL branch matching the version on the dev VM. Once the pull request (PR) is completed, that signals that Microsoft has officially accepted the change and it will show up in a future official release, usually the next monthly release (depending on what day of the month the release closes). The change will only enter the master branch of msdyncde through a future official release. Syncing to the tip of a REL branch will pull in other community changes submitted from that version.

Create a Bug or Feature depending on whether the change is related to incorrect behavior of existing code, or new behavior. https://dev.azure.com/msdyncde/cde/_workitems New work item > bug Fill in the title, assign it to yourself, and set the Area to your best guess as to where the behavior belongs (will help us review appropriately) In repro steps and system info, provide information on why this change is necessary
In Git, create a topic branch to work on. Branches are usually named by username/bug number. git checkout -b johndoe/482 git push –set-upstream origin johndoe/482
In Visual Studio make changes to Application Suite SYS code as normal. Changes are actually being made directly in the Git folder.
Push your changes to VSTS. git add -A git commit -m “Message explaining what is being changed” git push
Send a pull request from VSTS https://dev.azure.com/msdyncde/_git/cde/pullrequests?_a=mine New pull request Source branch = johndoe/482, Destination branch = Rel_8.0.30.8022 (or whatever version you have) Fill in the title and description, link the work item > Create

Any feedback from Microsoft reviewers (or other Community reviewers) will show up in the PR. Changes can be made to the PR by editing in Visual Studio, and doing git add / commit / push again. Once Microsoft has signed off, all comments have been resolved, a work item is linked, and all other polices have been met, then you can click Complete to complete the pull request. When a PR is completed, that is official acceptance by Microsoft that the change will become part of a future official release, usually the next monthly release.

Behind the scenes

The powershell script starts by checking what version of source code exists on the VM by examining the K:\AosService\PackagesLocalDirectory\ApplicationSuite\Descriptor\Foundation.xml file.
It then checks out the REL branch associated with that version, which matches the platform and other model versions currently on the machine.
The development config files are updated to allow changes to SYS models, which is normally disallowed on dev VM’s.

In addition to having an accelerated approach to get fixes into main branch, participants also have some more benefits. You will have access to the latest & greatest code changes through all code branches that Microsoft makes available. You can search through the code and see if there are code changes that affects extensions or code that is local to you installations. You can also see how the Microsoft code is evolving and improvements are made available in the standard application. You will also build gradually very valuable network towards the best developers in the world, where you will discuss technical topics with the actual people creating the world’s best ERP-system. One final joke for those considering going into this program: Git and sex are a lot alike. Both involve a lot of committing, pushing and pulling. Just don’t git push –force

D365F＆O – 社区驱动工程 / D365 &O Community Driven Engineering