Customer Engagement & Dynamics CRM Forum

Expand all | Collapse all

Deployment Plan

  • 1.  Deployment Plan

    Posted Sep 24, 2019 09:12 AM
    Hi guys,

    I started as an apprentice software developer 3 months ago and my main focus is our CRM. Prior to my involvement, all customisations were done directly on the default solution.

    Since I started, I've been going through the MB200 training and have since built a couple of small solutions for different departments within the business. I started having real problems importing my solutions into Production from Staging as I'd always get down to one JavaScript file (attached to a form) that the import process didn't like as it said it couldn't calculate if the file had any dependencies. I tried to delete it and it wouldn't let me (it was some sort of XML Error if I remember rightly).

    I believe one of the issues with our system is that a custom entity was built, Business, and made a parent of Accounts (which was renamed Offices) and this had lead to lots of issues. I've been tasked with rectifying this after it was initially given as a job to an external agency who subsequently let our firm down.

    We currently have 3 environments:

    1. Production - this is configured as described above
    2. Staging - this has a copy of the Production environment without the data. I've used this instance to test the deletion of the Business entity and I managed to get this done and have documented all the steps (I had help from Microsoft support who were great)
    3. Dev/Testing - this was reset back to a vanilla install and I've built a solution on here where I just renamed Account to Business and then created an Office entity as a child.

    My manager is asking me to come up with a deployment plan and I'm feeling a little bit nervous/out of my depth due to the fact that I had export/import issues before and now have three environments all in different states, I've only really skimmed through MB200.4 Power Platform test and deploy so I definitely need to work through that fully but I doubt it's going to be specific enough to what I'vegot  going on so I'm not 100% sure it's going to give me the answer.

    I've been thinking about it and two options spring to mind:

    1. Copy (inc. data) Production to Staging and make the customisations directly and then test etc before copying back
    2. On Staging (where I've deleted the custom entity Business), rename the Office entity (which is actually Account entity) to Business and then import the solution (unmanaged) from Dev/Testing. If this is successful, the end goal would then be to import into the Production environment also.

    Apologies for the life story but I think it's necessary and could really do with an experienced voice to nudge me in the right direction. My predecessor is no longer employed by the business and there are a couple of people with some D365 knowledge but not to the point where I feel like they can provide the answer to this conundrum.

    Would really, really appreciate some feedback on this one guys.

    James Ryan
    Practical Vision

  • 2.  RE: Deployment Plan

    Posted Sep 24, 2019 10:36 AM

    Here are a couple of suggestions. If you were able to successfully remove the custom entity from your test environment and have the steps documented, you should be able to repeat them in the production environment. If you do a solution export/import it will not delete the entity from production, that has to be done in the target environment manually.

    For the JavaScript dependency issue, I would do smaller export/import operations with just a few things in a solution. For example, put the JavaScript web resource in a solution and export/import it. Then, export/import the form that is referencing it. That way, you are sure that the resource is in the target environment prior to the system trying to calculate dependencies. You can have lots of things in an unmanaged solution and it may work fine, but when it doesn't it becomes more difficult to troubleshoot.

    Keep in mind that solutions are simply containers for holding things to be moved from environment to environment. Be really careful with "delete" vs. "remove". Removing something from a solution is much more common than deleting. When you delete, it actually truly deletes it from the system (from the default solution and any other solutions that had it). Removing just takes it out of that particular solution.

    The publisher that you specify for a solution will be used as a prefix for entities created in that solution and for attributes on those entities. If you create entities and attributes in the default solution they get a "new_" prefix.

    #customer engagement #technical​​

    Andy Arndt
    Minitab, Inc.
    State College PA

  • 3.  RE: Deployment Plan

    Posted Sep 24, 2019 11:14 AM
    Hi Andy,

    Thanks for taking the time to answer bud - I really appreciate it. I'm happy that I can delete the entity now. It's going to be quite daunting rebuilding it though as there are so many processes and associated components - somewhere around 100. It took me 4 hours to delete them all so It's gonna be a hell of a task to actually build and test them all!

    I think that's probably the most important part of the process now that I've had time to think about it. It's all fine and well me being able to get what I build to Production - it also needs to work as expected!

    I'm starting to think that copying Production to Staging is probably the way forward. It's not really a solution context when you're trying to reconfigure entities that are integral to everything else is it?

    Thanks again bud,

    James Ryan
    Practical Vision

  • 4.  RE: Deployment Plan

    Posted Sep 25, 2019 09:35 AM

    I used to work with SAP and find it be one of the most robust development environments among the various erp systems. I would suggest taking a look at this presentation and adopt it to your Crm landscape. The 3 system landscape should fit you nicely.

    Rex Kenley Tan, MCSD: App Builder
    Tallmadge OH

    *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.

  • 5.  RE: Deployment Plan

    Posted Sep 25, 2019 09:48 AM

    Thank you for sharing that. I certainly want to adopt best practices and improve both my knowledge and the CRM as time goes by. I'll be watching the presentation this afternoon if I can fit it in.

    Just looking at where you're from - my stepson's Surname is Talmage - pretty similar!

    Thanks again Rex,

    James Ryan
    Practical Vision

If you've found this thread useful, dive deeper into User Group community content by role