Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Customer experience | Sales, Customer Insights,...
Suggested answer

when should clone solution be used ?

(0) ShareShare
ReportReport
Posted on by

Hello

I am embarking on a customization/ migration project and solution layering, patching, upgrading are all coming into play. 

Say we have Dev --> QA --> PROD environments

Note - Internally, we have still been exporting from Dev to QA as an UNMANAGED solution. From all the readings, it seems that we should export as MANAGED (?) (Any insight here is welcome)

Scenario for my question regarding patches:

  • Day 1: Base solution is created in DEV and exported to QA
  • Day 2: Patch is created in DEV.

For now, I also exported the patch separately and imported to QA. Up until now, DEV and QA match exactly.

But, when do I clone Solution? What is the trigger to know when to clone the solution? Because now when I have to import to PROD, I definitely need to clone solution, which I presume I will do from DEV ? At that point, DEV and QA will not match anymore.

What is the recommended practice : as soon as I clone solution in DEV, should I also clone in QA ?

Also, MSFT documentation says we cannot delete patches, but I've seen on Youtube videos people mentioning you can delete patches. Thought I'd mention since that can influence when to Clone Solution.

Thank you in advance for your help.

[View:https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/use-segmented-solutions-patches-simplify-updates?view=op-9-1:320:240]

Thank you 

  • Suggested answer
    saad nadir Profile Picture
    on at
    when should clone solution be used ?
    Microsoft has shifted its stance on the usage of patches and no longer recommends them for Dynamics 365. There are two primary ways to move your solution to higher environments: Update and Upgrade.
     
    • Update Method: This is ideal for implementing quick changes without affecting any components you may have removed in your development environment. To signify an update in your version numbering (W.X.Y.Z), it's advisable to increment the "Y" segment. The "Z" segment can be auto-generated by Azure DevOps pipelines whenever an automated export occurs from your DEV environment.
    • Upgrade Method: This is your go-to approach for comprehensive deployments that include the removal of components initially existing in the DEV environment. Before initiating an upgrade, it’s recommended to clone your solution in the development environment which force the change of "X" or/and "Y". For version numbering, increasing "W" usually aligns with major releases for production, while increasing "X" is used to match the sprint number in your project's Agile methodology.
    For further information on Microsoft’s recommendations, refer to the official Dynamics 365 FastTrack Architecture Insights: https://learn.microsoft.com/en-us/shows/dynamics-365-fasttrack-architecture-insights/alm-transitioning-from-unmanaged-to-managed-solutions
     

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Daivat Vartak – Community Spotlight

We are honored to recognize Daivat Vartak as our March 2025 Community…

Announcing Our 2025 Season 1 Super Users!

A new season of Super Users has arrived, and we are so grateful for the daily…

Kudos to the February Top 10 Community Stars!

Thanks for all your good work in the Community!

Leaderboard > Customer experience | Sales, Customer Insights, CRM

Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans