kurthatlevik: D365F&O – Community Driven Engineering

[Blog bot]

Источник: https://kurthatlevik.com/2019/04/23/...n-engineering/
==============

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:

1. You create a bug or a Feature in CDE Azure DevOps
   
2. The bug or Feature is reviewed by the MS team and accepted or rejected
   
3. You create a branch for this work and commit in this branch
   
4. When done you create a Pull Request
   
5. The Pull Request is reviewed by the MS team and feedback is provided
   
6. After some iterations the Pull Request will be approved and complete
   
7. 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.

1. 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.
   
2. Make sure you have opened Visual Studio at least once on the VM to sign in and pick default settings.
   
3. Install Git on the machine from https://git-scm.com/downloads . The default installation options should work fine.
   
4. 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
   
5. Define your user name and email in Git
   git config –global user.name “John Doe”
   git config –global user.email johndoe@example.com
   
6. Mount the git repo into the F&O deployment
   pushd K:\git\cde
   powershell .\Mount.ps1
   
7. 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.

1. 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
   
2. 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
   
3. In Visual Studio make changes to Application Suite SYS code as normal. Changes are actually being made directly in the Git folder.
   
4. Push your changes to VSTS.
   git add -A
   git commit -m “Message explaining what is being changed”
   git push
   
5. Send a pull request from VSTS
   https://dev.azure.com/msdyncde/_git/...quests?_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


 


 



Источник: https://kurthatlevik.com/2019/04/23/...n-engineering/

[Vadik]

Цитата:

Сообщение от Blog bot

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

Цитата:

Том взял кисть и начал красить забор, изображая из себя человека, занятого важным и интересным делом. Когда к нему подошел мальчик Бен Роджерс и стал над ним издеваться, намекая, что Тому приходится работать, тогда как он идет купаться и играть, Том ответил, что белить забор гораздо интереснее и не каждому мальчику доверят такую ответственную работу.

Ситуация изменилась. Бен, видя с каким упоением Том красит забор, стал постепенно меняться в лице и, наконец, попросил Тома дать попробовать покрасить и ему. Том, ликуя в душе, отказал, указав на ответственность поручения. Тут Бен окончательно попался в ловушку. Он отдал Тому яблоко, лишь бы тот разрешил немного побелить забор

Еще можно отдавать тикеты из поддержки. Не всем, совершено понятно, а только самым опытным и знающим

[fed]

Цитата:

Сообщение от Vadik

Еще можно отдавать тикеты из поддержки. Не всем, совершено понятно, а только самым опытным и знающим

Дык сделано давно уже. Я еще году в 2007ом видел некий внутренний документ, где описывалось что community.dynamics.com (который тогда, правда, на другом домене жил) сэкономит микрософту деньги на поддержке. Типа, если кто-то туда тиснул вопрос, то надо подождать пока какой-нибудь энтузиаст ответит. А вот если энтузиаста за три (кажется - уже не помню), дня не нашлось, и задавший вопрос находится на поддержке (или расширенной поддержке - опять же не помню), то сотрудник поддержки должен на этот вопрос ответить.

[Stitch_MS]

Цитата:

Сообщение от Blog bot

Git and sex are a lot alike.

За исключением одного - получением удовольствия.

[skuull]

На самом деле, некоторые достаточно большие ИСВ тупо замахались ждать пока им напишу все екстеншены что им надо и МС дал им доступ к этому. Вы если подпишетесь то увидете, они там в основном и трудяться, но они не баги фиксят

[ax_mct]

Цитата:

Сообщение от skuull

На самом деле, некоторые достаточно большие ИСВ тупо замахались ждать пока им напишу все екстеншены что им надо и МС дал им доступ к этому. Вы если подпишетесь то увидете, они там в основном и трудяться, но они не баги фиксят

В ISV driven верится, в community driven fixing не очень. Вот если бы Microsoft обьявил призы за нахождение багов, но они же не идиоты, они других за идиотов держат.

Цитата:

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.

[ax_mct]

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.

Цитата:

Сообщение от Stitch_MS

За исключением одного - получением удовольствия.

Не знаю как с технической стороны, но с психологической GIT на стороне зла.

IT community в широком смысле хочет
Application portability: applications can run on any cloud, there are no cloud specific services used.

И тот же GitLab в отличие от Git по крайней мере рассматривает всерьез идею multi-cloud.

https://medium.com/gitlab-magazine/m...l-2de185c01dd7
https://www.cncf.io/

Мне кажется что это серьезный тренд когда зло в привязке цепями к конкретному облаку.
А community оно любит быть на стороне добра и свободы.