This readme file explains how to run the Headless Commerce extension samples and consume the reference package from the public feed for Dynamics 365 Commerce extension development.

This repo contains code samples, templates, and tools that are required to extend or customize existing Commerce functionality, samples are published into different repos in GitHub based on the Commerce extension components. This topic applies to Dynamics 365 commerce application version 10.0.16 or greater. For earlier version refer this doc.

This repo contains the sample code for how to customize the Commerce runtime (CRT), Headless Commerce APIs and channel database.

The samples in the repo are organized by Dynamics 365 Commerce application release, each branch in the repo points to an application release of Dynamics 365 Commerce, use the right release branch based on your go-live version.

Note: The repo contains only samples, so its not required to clone this repo.

Extension repository:

Extension code or repository if required can download and consume the samples and templates from microsoft/Dynamics365Commerce.ScaleUnit, the sample scale unit repo contains nuget.config, repo.props, CustomizationPackage.props and build pipelines script which provide guidance on how extension can setup the repo metadata files.

Samples for instore components like Modern POS, Cloud POS, Hardware station and Cloud scale unit – Self hosted are published in the Dynamics365Commerce.InStore repo.

Readme file inside the Commerce Runtime, ChannelDatabase and ScaleUnit contain more details on how to run the samples. Analyzers readme at the root of the repo describes all the Commerce and standard .NET code analysis rules enabled for extension projects.

If you don't need POS or other samples from the repo, exclude the corresponding projects from the solution.

Download reference packages for creating Commerce extension APIs and consuming messages, request, entities, and contracts:

Commerce contracts, messages, entities, and request packages are published in this public feedfor commerce extension code to consume and customize existing functionalities or build new functionalities for Dynamics 365 Commerce product.

Consume the commerce packages from this location, extension can add package source location in the nuget.config of their extension project file.

<packageSources>
    <add key="dynamics365-commerce" value="https://pkgs.dev.azure.com/commerce-partner/Registry/_packaging/dynamics365-commerce/nuget/v3/index.json" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>

Commerce packages available in the public feed:

Package versioning:

Extension project can consume the correct version by adding the package reference to the project with full version number or use wild card to always get the latest version, recommend option is to use the full version number and update the version based on your go-live version.

<PackageReference Include="Microsoft.Dynamics.Commerce.Sdk.Runtime" Version="9.50.x.x" />

Or

<PackageReference Include="Microsoft.Dynamics.Commerce.Sdk.Runtime" Version="9.50.*" />

Or

// Available in Visual Studio version 16.6, NuGet version 5.6, .NET Core SDK version 3.1.300
<PackageReference Include="Microsoft.Dynamics.Commerce.Sdk.Runtime" Version="9.50.*-*" />

With every hotfix and new application release, new version of the package will be published in the same public feed, consume the right package version based on the version required for your go-live. Consuming the higher version of the package than your go-live application version may result in runtime and deployment failures.

Setup Azure DevOps pipeline for build automation and package generation:

Set up a build pipeline for the independent-packaging SDK

Best practice and branching strategies:

Detailed information on git branching strategy refer Git branching strategy doc.

The following branching strategies are based on the way we use Git here at Microsoft. For more information, see How we use Git at Microsoft.

Keep your branch strategy simple. Build your strategy from these three concepts:

• Use feature branches for all new features and bug fixes.
• Merge feature branches into the main branch using pull requests.
• Keep a high quality, up-to-date main branch.

Create a new feature branch for development and bug fixes:

Create a new feature main branch for our extension, follow the proper naming convention (refer the Git branching doc for sample naming convention)

Create a new development branch:

Create a private branch for the development:

- git checkout -b private/{username}/{feature/description}

Add and commit new changes to the development branch using git -add . and git commit -m" commit message."

After the development is completed, tested, and validated push the changes to the main branch by doing git push <remote> <branch>

- git push origin {private branch name}

Create a release branch after development:

After the development changes pushed into the main branch, create a new release branch, and create the deployable packages from the release branch.

- git checkout -b release/x.x.x

Merge the changes from the release branch back to main branch if any changes done in the release branch.

- git checkout master git merge release/x.x.x

Extension hotfix branch:

Like release branch, create hotfix branch for extension from main branch and release the fix and later merge the changes back to the main branch.

Merge new release branch to main and development branch:

After a new version of the samples released, if required merge your development branch with the new branch. The repo contains only samples, so it's not required to always get the updated changes from the branch.

- git checkout master git merge release/x.x.x