Customer Engagement & Dynamics CRM Forum

Expand all | Collapse all

Unmanaged Customizations to Managed Solution

  • 1.  Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 09, 2019 01:48 PM
    Hi everyone,

    @Nicholas Arbour​​ asked a fantastic question the other day about adding existing components to a new solution and it got me thinking about something I've been wrestling with that I haven't had a chance to test. Does anyone have any experience adding existing, unmanaged components to a new managed solution, and if so, can you any lessons learned or things to watch out for? I'd like to take a bunch of customizations we've made over the past 8 years that aren't part of any single solution, bundle them up into a monolithic solution, and "redeploy" them as managed.

    A Little Background...
    I've been working on our Dynamics development "team" (just me now, was once me and one other) since around 2016. My company adopted Dynamics around 2012. When I first joined the team, all of our customizations were made directly to the default solution and moving from Dev -> QA -> Prod involved manually applying the same customizations as Dev in each environment. No solutions were used to bundle things up and make the deployment process easier. I don't know why things were done this way, but this is how things were done at the time.

    When I became a team of one, I started to look into ways to at least make the transport process easier and less error prone. I've been using unmanaged solutions for the past few years. For each sprint, I create a new solution (ex: Sprint 50), I apply my customizations to that solution, and them transport them between the environments when the time comes. This works well, but now I've got countless "Sprint XX" solutions applied to each environment. I clean things up occasionally by deleting some of the older sprint solutions. Since they're unmanaged, the customizations stick around.

    Now, I'd like to collect all of the customizations we've made over the years into a single, managed solution, that I can put under source control and automatically deploy using an Azure DevOps pipeline. I've done the same for another, newer, Dynamics-based system we have here and it's worked great. I'm just wary of doing this in the event that going from unmanaged to managed messes something up.

    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------
    Conference-CRMUG_200x200


  • 2.  RE: Unmanaged Customizations to Managed Solution

    SILVER CONTRIBUTOR
    Posted Sep 09, 2019 04:37 PM
    Edited by Laurent Maneville Sep 09, 2019 04:39 PM

    Hi Steve,

    Going from unmanaged to managed is easy! Just export as managed and your done ! Moreover, With Azure DevOps pipelines, it is easy to automate export in unmanaged and managed at the same time. Then, when importing to a new environment, you could choose the manage or unmanaged version. This will also be very helpfull if for any reason your dev environment is lost.

    Maybe be a bit more carefull when importing this new big managed solution in another environment, do a first test in copy of the instance to check if everything is correct.

    I think that your greatest work will be to create the Big Solution! If you still have the previous sprint solutions (or perhars the zip files for the older ones ?), you could use the wonderfull "Solution Component Mover" from XrmToolBox to help you.

    In the future, you may consider using "Clone a patch" from your big solution to manage each of your sprints !

    Best regards,



    ------------------------------
    Laurent Maneville
    Nmédia
    Drummondville QC
    ------------------------------

    Conference-CRMUG_200x200


  • 3.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 10, 2019 03:07 AM
    There are lots of opinions regarding managed vs unmanaged solutions on these forums!
    I would ask why with a dev team of 1, why you are considering moving to managed solutions?

    We used managed solutions when we started out here and eventually had to revert to unmanaged.
    For me, managed solutions are for:
    • Third party solution vendors
    • Complex and well managed environments - one where you can be sure no one will ever make any changes to production

    For small one, two dev environments, managed solutions are overkill that eventually come back to bite you (again - IMO).


    ------------------------------
    Donal McCarthy
    Digital Marketing Administrator
    BrightWork
    Galway
    ------------------------------

    Conference-CRMUG_200x200


  • 4.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted Sep 10, 2019 05:41 AM
    Hi @Donal McCarthy :)
    Just out of curiosity - why would the team size affect a choice of deployment method?​​
    (not trying to be sarcastic - I'm interested in the reasoning)

    ------------------------------
    Jonas Rapp
    MVP
    Sweden
    ------------------------------

    Conference-CRMUG_200x200


  • 5.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 10, 2019 05:49 AM
    No probs @Jonas Rapp but it seems kind of obvious to me!
    The more moving parts there are, the more likely you are to benefit from managed solutions.

    ------------------------------
    Donal McCarthy
    Digital Marketing Administrator
    BrightWork
    Galway
    ------------------------------

    Conference-CRMUG_200x200


  • 6.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 10, 2019 10:07 AM
    As a dev team of one, I'm considering moving to a managed solution because of the control and assurance it gives me that each of my environments have the same customizations applied. It also removes or reduces the urge to just apply a fix or change directly in each environment because it's "faster". Lastly, I may not always be a dev team of one.

    My end goal is to require that all changes move through a well-defined and easily auditable pipeline in Azure DevOps. I want to know what changed between each deployment and see a clear relationship back to a user story or bug report. I've got this working for a newer solution now, but need to go back to our (historically) less controlled environment and implement this process.


    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------

    Conference-CRMUG_200x200


  • 7.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 10, 2019 07:23 AM

    I would NOT recommend going to manage, especially if you are the only developer for an in house solution. If you are selling your solution then managed is the only way to go. But for in house projects managed solutions just add unnecessary headaches. Remember that managed is an all or nothing deal. It is a lot easier to remove components in an unmanaged solution and VERY painful in a managed solution.

    And if you use patches, you are out of luck with managed.

    - A patch is created for unmanaged solution. You can't create a patch for a managed solution.

    https://docs.microsoft.com/en-us/dynamics365/customer-engagement/customize/use-segmented-solutions-patches-simplify-updates



    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------

    Conference-CRMUG_200x200


  • 8.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted Sep 10, 2019 08:14 AM
    Hi Rex,

    I'm not going into the managed/unmanaged discussion, but want to add a note to your statement about patches:

    The bullet you quote means you cannot create a patch from a managed parent solution​. So no, you cannot create a new patch solution in Test or Prod (where the solutions would be managed).
    You do however create patches for the unmanaged solutions in Dev that you would export as managed, and similarly you export the patches as managed to patch a managed solution in the target environment.

    The very next bullet states:
    - When you export a patch to a target system, you should export it as a managed patch. Don't use unmanaged patches in production environments.

    Distributing unmanaged patch solutions makes no sense, you might as well just create yet another unmanaged solution then to add changes to target environments. Managed patches have the advantage of "knowing" they are patches to a specific solution, so you secure the dependency in target environments and can utilize the Clone behavior when you want to wrap up all patches to a new version of the delivery.

    So regardless if you go for managed or unmanaged approach, patch solutions are only relevant for managed distribution.

    Then again - the original question was never if they should switch to managed approach 😉

    ------------------------------
    Jonas Rapp
    MVP
    Sweden
    ------------------------------

    Conference-CRMUG_200x200


  • 9.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 10, 2019 08:40 AM
    Edited by Rex Kenley Tan Sep 10, 2019 09:12 AM

    Jonas

    How would one remove a component in a managed solution? If I have unmanaged, then it is a simple delete of the component. I still haven't found a painless way of doing so in managed.

    I have to disagree about the "insensibility" of unmanaged. We have a dev, stage, prd environment utilizing devOps. We have been using unmanaged solutions to promote enhancements, changes and patches between environments without any issues. Yes, there is more responsibility with managing the components, but at least we have that freedom without being bogged down by a managed container. Managed solutions would lock you down.  

    I know MS has been pushing for us to use managed. But it still doesn't make sense to me as to why we should do it for an in house solution with all of its restrictions with no clear benefits. I would appreciate it if you can provide any info that would cite these managed benefits.

    *****

    "I'm just wary of doing this in the event that going from unmanaged to managed messes something up."  - original post

    I may be mistaken, but I thought Steve was trying to find out what cost he would be paying for the benefit of not having to clean up old unmanaged solution containers.

    *****

    Found the answer to my primary concern, but how difficult is it to incorporate the process to devOps?

    https://www.henryjammes.com/2018/09/how-to-delete-components-from-managed-solution.html

    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------

    Conference-CRMUG_200x200


  • 10.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 10, 2019 09:57 AM
    Unless I'm thinking of something different, it's fairly painless to remove a component from a managed solution, at least in the testing that I did. I find it far more difficult to remove a component from an unmanaged solution.

    Managed
    Delete the field, form, etc. from the solution.
    Publish the managed solution to QA.
    Publish the managed solution to PRD.

    Unmanaged
    Delete the field, form, etc. from DEV.
    Publish the solution to QA.
    Delete the field, form, etc. from QA.
    Publish the solution to PRD.
    Delete the field, form, etc. from PRD.

    For me, managed solutions align much better with how I think and how traditional software development and ALM work. I can be fairly confident that if version 1.X is deployed in Environment A and Environment B, then those two environments will have the same components and customizations applied as part of that solution. The same can't be said for unmanaged, because you can remove a component from the solution and forget to remove them from downstream environments.

    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------

    Conference-CRMUG_200x200


  • 11.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 10, 2019 10:19 AM
    Edited by Rex Kenley Tan Sep 10, 2019 10:20 AM

    Steve

    Based on the article I posted, I think you are missing a few steps. The author specifically stated.

    If you try to delete one the components manually in production, you will get this kind of error, because the components are in a managed state.

    To which he then outlined the required steps to create a clone solution which you then merge with your target solution.

    1. Clone your solution (optional) and update the version number
    2. Delete the field, form, etc. from the solution.
    3. Deploy the clone managed solution to your target managed environment
    4. Apply the Solution Upgrade in your target managed environment (instead of just publishing)

    Repeat 3-4 for PRD.

    And you are correct about what you said about managed and unmanaged. But I think you will encounter some difficulty when it comes to DevOps. You need an Azure component that would do the managed upgrade merge (I don't think there is one yet) or you will have to write a custom powershell script to do the aforementioned steps. This is not a problem for unmanaged as the necessary components are readily available.

    https://github.com/WaelHamze/xrm-ci-framework

    Cheers!



    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------

    Conference-CRMUG_200x200


  • 12.  RE: Unmanaged Customizations to Managed Solution

    Posted Sep 10, 2019 11:11 AM
    Ah, the old debate over managed vs unmanaged.  Steve, I like your idea to implement an auditable pipeline for deployment, I think its a great solution to help you in the future.  I also share some of the hesitation around managed solutions, but will point out that with every version, Microsoft makes deploying and dealing with managed solutions more and more like custom code deployment, so I think ongoing you'll be ok.  A few notes based on this thread:
    1. To delete items from the system (i.e. actually remove a field from the database, for example) with managed solutions you actually have to follow a much longer process.  Dynamics will not remove something it does not find within a solution being imported, so your steps (delete the item from the solution then publish to environments) will not actually remove the item.  Rex lays out some added details there.
    2. We should be clear on when a solution becomes managed.  Everything in your development environment will always be unmanaged, because a solution does not become managed until it is exported as managed, and then imported elsewhere.  Once it is managed, then you cannot change it in the target.
    3. The limitations for internal use are real.  Imagine a situation where you do what you intend, build the big managed solution and re-deploy it to production so that everything there is managed.  You are having a fine time updating with patches or new managed solutions and life is wonderful.  But one day you decide that the development org could use a data refresh and so you copy your production down to dev.... and now all of your config is managed and you cannot change those solutions directly again.  To maintain this managed pipeline, dev must always be there (or you should keep unmanaged copies of your solutions in source control as well) because without the source unmanaged solution you can never again export the solution.

    I'm no DevOps expert, but could you create the same automated deployment pipeline with unmanaged solutions instead?  Gain the benefits of automation and traceability but keep the flexibility of unmanaged solutions?  Just a consideration!

    ------------------------------
    Merlin Schwaiger
    Director of Solution Design
    PowerObjects, an HCL Company
    Minneapolis MN
    ------------------------------

    Conference-CRMUG_200x200


  • 13.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 10, 2019 11:25 AM
    I've been following the managed vs. unmanaged debate for what feels like years now and the cons have always scared me off until recently. It seems like the process has gotten better over the past few years!

    You bring up a good point about the 'ol dev refresh from production. That's something I hadn't fully considered, but I think would be possible to work around given that both managed and unmanaged solutions are being stored in source control. I'm using the SolutionPackager tool that comes with the SDK to export the solution in both formats, unpack them into a format that works well (better) for source control, and store that way. Deployments pull the "raw" files, package them back into a zip file (using the SolutionPackager), and then deploy to the target environment. For a dev refresh, it's possible that I could remove the managed solution and then redeploy from the unmanaged configuration in source control. I'd lose data (not a big deal since I don't have production data in dev and have only done a minimal copy back to dev) and it'd be a huge pain, but it would be possible.

    I also think your idea of unmanaged all the way through would work as well, with the downside that there could be some manual steps that need to be performed in each environment after a deploy, such as deleting components. It's not the end of the world, but maybe that's the better place to start. Less risk from a managed solution standpoint and I suppose I could switch to a managed solution at some point in the future should the need arise.

    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------

    Conference-CRMUG_200x200


  • 14.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 10, 2019 11:54 AM
    Edited by Rex Kenley Tan Sep 10, 2019 11:56 AM
    If MS provides a tool to convert managed to unmanaged for the dev refresh scenario, I predict it would be ZERG RUSH to manage solutions ;)

    http://i.imgur.com/KJnk9.gif
    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------

    Conference-CRMUG_200x200


  • 15.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted Sep 10, 2019 10:02 AM
    Hi - I was referring to the statement around Patch Solutions, which I believe was misunderstood. Reading the quoted bullet alone can absolutely give the impression that you have to distribute unmanaged solutions to get the benefits of it, while it is actually the opposite.

    ------------------------------
    Jonas Rapp
    MVP
    Sweden
    ------------------------------

    Conference-CRMUG_200x200


  • 16.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 10, 2019 10:57 AM
    @Jonas Rapp You may be right.

    @Rex Kenley Tan I've got a DevOps pipeline implemented using a managed solution right now that works quite well. In setting everything up, I made sure to test the removal of components and their effect on the downstream environments. I ultimately ended up using the following Powershell commands as part of my process to deploy everything.

    $existingSolutionResult = Get-CrmRecordsByFetch `
                  -conn $connection `
                  -Fetch $fetch

    Import-CrmSolutionAsync `
                  -conn $connection `
                  -ImportAsHoldingSolution:($existingSolutionResult.Count -eq 1) `
                  -BlockUntilImportComplete `
                  -MaxWaitTimeInSeconds -1 `
                  -ActivateWorkflows `
                  -SolutionFilePath $(System.ArtifactsDirectory)\drop\packedSolution\$($env:SolutionName)_managed.zip

    $upgradeSolutionRequest = New-Object Microsoft.Crm.Sdk.Messages.DeleteAndPromoteRequest
    $upgradeSolutionRequest.UniqueName= $env:SolutionName
                
    $response = $connection.ExecuteCrmOrganizationRequest($upgradeSolutionRequest)

    This post was the basis for much of the pipeline I configured. The things that post is missing that I ended up adding are:

    • -ImportAsHoldingSolution switch when importing the solution. This stages the solution for upgrade.
    • -ActivateWorkflows switch to ensure that plugins and workflows are deployed in the desired state.
    • The last three lines to execute a promote request that upgrades the solution, which removes any deleted components. 


    ------------------------------
    Steve Platz
    Technical Lead, Commercial Excellence
    LORD Corporation
    Cary NC
    ------------------------------

    Conference-CRMUG_200x200


  • 17.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 10, 2019 11:13 AM
    Thanks Steve! :) Over 9k points for you!

    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------

    Conference-CRMUG_200x200


  • 18.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted Sep 10, 2019 12:19 PM
    Looks like you've got a nice setup there @Steve Platz that even MS solution platform gurus would approve of :)
    We know Wael's CI stuff has been around a few years, but have you tried the preview from MS as well?
    https://marketplace.visualstudio.com/items?itemName=microsoft-IsvExpTools.PowerApps-BuildTools

    @Merlin Schwaiger to your #1 I'd like to comment that yes, there is a quite heavy process to delete components. But the upside is: there IS a process that is supported even through CI/CD automation :) Going unmanaged, sure it is easy enough to delete something from PROD, but you have to do it manually... which not all governance policies approve of.
    ​​

    ------------------------------
    Jonas Rapp
    MVP
    Sweden
    ------------------------------

    Conference-CRMUG_200x200


  • 19.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted Sep 11, 2019 06:15 AM
    Hi Jonas, developers shouldn't be doing anything manually in production. Just because you need to delete something from an unmanaged solution is no excuse: script it up! I have 15 devs in three Scrum teams developing features in two branches (current production instance and our next big release). We have about 10 instances to manage so we script everything we can. Hardest thing to script so far has been the Data Export Service -- not even Wael had a good answer for that one.

    ------------------------------
    Neil Benson, MVP
    Customery
    Brisbane, QLD, Australia
    https://customery.com/blog
    ------------------------------

    Conference-CRMUG_200x200


  • 20.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted Sep 11, 2019 06:28 AM
    Keep it up, Neil Quijote 😊
    Completely agree there, I'm just lazier and cross my fingers (every time) that I can use the MS ALM strategy instead of inventing my own. Well I already did that, but that was before MS even had that story. Of course there are still gaps, like the DES.

    ------------------------------
    Jonas Rapp
    MVP
    Sweden
    ------------------------------

    Conference-CRMUG_200x200


  • 21.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 12, 2019 02:15 PM
    Thanks for the update Jonas and others,

    This thread is way above my payscale - so per the advice from Jonas, I've asked an ALM/PowerApps BuildTools expert from Microsoft to maybe provide some input as well.  Let's hope, enough peer pressure will summon the infamous @Shan McArthur to response to this thread and see what Microsoft thinks?​

    Cheers,
    Tony

    ------------------------------
    Tony Stein
    D365UG, GM
    Dynamic Communities
    Fargo ND
    ------------------------------

    Conference-CRMUG_200x200


  • 22.  RE: Unmanaged Customizations to Managed Solution

    Posted Sep 16, 2019 01:19 PM

    There are a number of inaccurate statements in this thread and I want to shed some light on the topic and where we are going.

    Here is the official statement for the use of managed and unmanaged solutions and I hope that it helps add some clarity for the community: Unmanaged solutions are to be used in a development environment and to be exported and processed by Solution Packager to be checked into your source control system.  Managed solutions are to be used to deploy your solution to all other environments.

    Notice that at no point in that statement is team size, project complexity, or other dimensions a factor in the appropriate solution type.  It really is as simple as that.

    Deleting components is only possible through solution import actions if you are using managed solutions and if you use the stage for upgrade (or promote and delete) mechanic.  In the new UX, this is now the default behavior.  To delete a component, simply remove it from your solution in your development environment and export a newer version of your solution file (as managed).  Import that into your production environment using the stage for upgrade mechanic and the system will remove that component.

    We are making a lot of investments this year in making solutions more reliable and easier to work with.  We are adding many more components to solutions, cleaning up the UX, investing in making solution import a zero-downtime and non-disruptive experience, giving you better insights into layering, and the ability to undo active customization.  We are also shipping Azure DevOps tasks to help enable easy ALM automation.  ALL of our investments are based on the design of managed solutions.  Any advise to using unmanaged solutions for deployment is doing customers a disservice as it will put them on an unhealthy ALM path and will make it more difficult to use solutions and to automate ALM.  I find that most folks that are still advocating the use of unmanaged solutions are doing it because of their experience years ago and how difficult it was.  I would encourage them to refresh their knowledge and consider the proper way of using solutions to enable healthy ALM - whether they are a one person team or embedded in a larger project team.

    A quick checklist for everyone to self-assess your ALM health:
    1. You consider source control as your single source of truth and not a running environment.
    2. You check in your unmanaged solution files after they are unpacked using Solution Packager (or our unpack task in our DevOps tasks)
    3. You deploy managed solutions to all other environments (test, UAT)
    4. You run solution checker in your ALM pipeline
    5. All ALM operations are automated and do not require manual deployment steps to be taken
    6. There are no unmanaged changes in your production environment - all changes are brought through only using managed solutions.
    7. While you are developing a solution, your development environment will *only* have the direct managed dependencies installed and no other solutions, and you do not ship multiple solutions from the same environment.



    ------------------------------
    Shan McArthur
    Microsoft
    Regina WA
    ------------------------------

    Conference-CRMUG_200x200


  • 23.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 16, 2019 01:35 PM
    Edited by Rex Kenley Tan Sep 16, 2019 01:50 PM

    Shan

    What does MS recommend in the "Dev Refresh from Prd" scenario? It should be easy to just restore the Prd DB to Dev, change the managed solution to unmanaged and be on our merry (following the recommended) way. This feature has been requested since 2011 and so far no official solution nor guideline was given.

    As I have stated before, this is the only thing that is keeping us from going managed. Thanks!



    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------

    Conference-CRMUG_200x200


  • 24.  RE: Unmanaged Customizations to Managed Solution

    Posted Sep 16, 2019 05:55 PM
    The refresh dev from prod scenario is an incredibly unhealthy way to look at the problem and will only drive more unhealthy ALM problems down the road.  If you have unmanaged changes in production, the way to fix this is to create a solution in prod, add the unmanaged components with customizations to it, then export as managed.  Rehydrate a new clean dev org, import your unmanaged solutions from source control, then import your unmanaged solution from prod.  This will ensure that the changes in prod will be the last ones made and will be on the top of the stack.  Add any new components into your dev solution, then export, unpack, and check into source control.  Your next build will deploy those changes to prod and you will be healthy from an ALM standpoint AND be using managed solutions as well.  You will pass all of my healthy ALM checklists I just shared.

    ------------------------------
    Shan McArthur
    Microsoft
    Regina WA
    ------------------------------

    Conference-CRMUG_200x200


  • 25.  RE: Unmanaged Customizations to Managed Solution

    MICROSOFT MVP
    Posted Sep 16, 2019 09:39 PM
    Shan, thanks for diving into the user group community and providing clear guidance.

    Can I ask for a couple of favours?

    1. Can Microsoft help the community understand the benefits of managed solutions?
    My teams have been criticised on a couple of projects by Microsoft Consulting Services for transporting unmanaged solutions to production. Using managed solutions is more complicated, and we've been unable to see any benefit from that effort. MCS has been unable to express the benefits either. Until we all can believe a convincing case for managed solutions, most partners and customers will continue to take the easier path -- unmanaged solutions.

    2. Can Microsoft provide better guidance and training on managed solutions?
    Microsoft Learn has barely any content on managing solutions (this is all I can find: https://docs.microsoft.com/en-us/learn/modules/use-developer-tools-extend/). Microsoft Docs has ambiguous guidance, including an option to not use solutions at all! https://docs.microsoft.com/en-au/dynamics365/customer-engagement/developer/organize-solutions. Managed solutions have been improved a lot over the last couple of years, but our knowledge is out of date and the learning content is out of date too.

    3. Can Microsoft commit to closing the ALM gaps?
    An enterprise Dynamics 365 project will have a bunch of solutions, Azure resources, integrations, and configurations that need to be transported across environments. I have two full-time devops engineers in my team to manage this. There are still gaps in duplicate detection rules, Data Export Profile configurations and other items that aren't solution aware. We prefer LogicApps to Flow because we're not sure how Flow connections would play in a solution. I'm excited to see the investments Microsoft is making in Dynamics 365 extensions for Azure DevOps, but since there is already a robust community toolset available, I'd rather Microsoft focus it's resources on the gaps that the community can't close itself.

    ------------------------------
    Neil Benson, MVP
    Customery
    Brisbane, QLD, Australia
    https://customery.com/blog
    ------------------------------

    Conference-CRMUG_200x200


  • 26.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 16, 2019 10:05 PM
    Edited by Rex Kenley Tan Sep 16, 2019 10:08 PM

    Shan

    The "refresh dev from prd" is not for the sake of solutions/code, but for the sake of having a dev environment that has production data. As you have stated, unmanaged solutions is for the dev environment. So a feature that would allow us to easily change managed to unmanaged after a dev refresh would be perfect. This would allow developers to code and test against real world data and have "very near production" results.

    This is a common practice in many erp systems like SAP. It would be nice if CRM has this feature as well.

    Thanks for taking the time on this subject.

     



    ------------------------------
    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH
    https://www.youracclaim.com/users/rex-kenley-tan

    *Always be CURRENT with JavaScript & C#, NEVER be obsolete.

    DISCLAIMER: All views expressed on this site are my own and DO NOT represent the opinions of ANY entity whatsoever with which I have been, am now, or will be affiliated.
    ------------------------------

    Conference-CRMUG_200x200


  • 27.  RE: Unmanaged Customizations to Managed Solution

    SILVER CONTRIBUTOR
    Posted Sep 17, 2019 09:18 AM
    Hi,

    I really don't like the concept of bringing prod data to a dev environment, this may include real persons private information. This could be done to analyse and correct a specific bug in a test environment, but for this, you don't need to have an unmanaged solution, once it's corrected, just make the same correction in your dev environment.

    What is interesting to keep is Configuration data that is not transported with the solution. In our ALM procedures in Azure DevOps, we export solutions and configuration data and both are put in source control, ready to import in prod environment.

    The tool to export/import configurations we use is available on the marketplace: Dynamics 365 Data Migration Tool

    We are now waiting for the new lincensing model with unlimited instances, we will be able to create as many dev instances as we like, just importing the unmanaged version of the solution and the configuration data from source control and we are ready to go!

    We havn't yet used managed solutions in prod environment, but with all the improvments from Microsoft on this side, and the improvment on our ALM procedures, I think we are ready to try it!

    Best Regards,

    ------------------------------
    Laurent Maneville
    Nmédia
    Drummondville QC
    ------------------------------

    Conference-CRMUG_200x200


  • 28.  RE: Unmanaged Customizations to Managed Solution

    TOP CONTRIBUTOR
    Posted Sep 17, 2019 10:01 AM
    Edited by Rex Kenley Tan Sep 17, 2019 11:35 AM