locked
Can we make changes and publish CRM customization while it is in Production/Live and being used by Users? RRS feed

  • Question

  • The purpose of this question is to understand what happens when you publish CRM customization?

    • When you click on Publish customization, what does CRM do? Does it restarts the IIS? Can anyone share the internal process chart about what happens when you click publish?
    • Suppose a user is saving a CRM Account record and the System Customizer is publishing the Account entity at the same time when the user is saving the record. How will CRM react in this situation?

    While we know that the best practice is to customize CRM on a development environment and import those customization into the Production environment. My question would be to question "Why?"

    Thank you in advance.


    Best Regards,
    Gagandeep Singh
    http://mscrmnovice.blogspot.com

    Saturday, March 23, 2013 4:36 PM

Answers

  • No IIS reset happens when a publish occurs.

    Any forms and web resources required by that form would be the ones present when the form was opened.

    I'd be curious if someone had any solid documentation they could provide,

    I could imagine a situation where you made a change and published a different web resource that may be called indirectly from a form/resource and having the content essentially be "out of sync" with what was maybe loaded prior to the publish. 

    Same I imagine would work with any plugins - these aren't called until the related message is generated. So if a form was opened, then a publish of an update plugin was made - I could also envision a mis-match potentially between the form and plugin. 

    So if these items hold true - it would make most sense to publish updates on heavily used systems during off or non-peak hours. 


    Jason Lattimer
    My Blog -  Follow me on Twitter -  LinkedIn

    Saturday, March 23, 2013 6:10 PM
    Moderator
  • I don't know of any documented evidence to back this up, but from my experience this is what I've noticed.

    As you are publishing customizations, users may experience delays in navigating CRM. Very rarely I have seen SQL errors when someone is creating a field or relationship while someone else is publishing, but the changes are never lost and you can simply close the error and save again after the publishing is finished.

    If you are publishing changes to a web resource, for example a JavaScript library, and a user already has a form open which uses that library, the JavaScript won't be updated until they reload the form, so the old script will still be used while still in memory. Only when a web resource is requested again (eg from a ribbon button click, or form refresh) will the new web resource be used.

    Plugins are only called when that message occurs, so for example a plugin running on update of an entity will still fire even if you only just made changes to it while the user was updating a record. The plugin takes a collection of fields that have changed, so it doesn't matter if you've published changes to the form while the user is updating, as the plugin will still just take whichever fields were changed on the current form.

    So basically publishing should be fine, as it's usually quick enough that it's not a problem, but any extensive customizations should be done in a dev environment anyway so you can test and make sure it's correct before throwing it into production. Small hotfixes though, like modifying a JavaScript variable or something should be fine to just update and publish though.

    If you're deploying a solution however, depending on the amount of components these can take up to 20 minutes to deploy, and during that time the system will be offline so it's definitely best to do this after hours.

    Hope that helps

    Paul


    If my response helped you find your answer please show your thanks by taking the time to "Mark As Answer" and "Vote As Helpful".

    Twitter LinkedIn Facebook Blog Magnetism

    Saturday, March 23, 2013 9:09 PM
  • Hi,

    I'll just add a little to Paul and Jason's comments:

    1. When a new plugin is deployed, any existing executing plugins will complete since the old and new are held side-by-side. The same goes for Workflows. This is a really great feature.

    2. If your imported solution contains new attributes/entities - this can often cause SQL errors due to the re-creating of the Filtered Views and updates to the metadata. 

    3. When a solution is published, a new client 'cache key' is created, meaning that on the next load of any pages, the webresources are re-downloaded and cached since the directory path changes.  See http://www.develop1.net/public/post/CRM-Developer-e28098Must-Knowe28099-2-Web-Resource-Caching.aspx

    4. Some published features such as Ribbon Commands require the Async Server to invalidate the server cache, and so can sometimes take longer than other features to appear.

    5. When publishing new workflows, you'll need to deactivate the old before replacing it (unless create an entirely new one). Either way, there is going to be some downtime. To get around this you can create a master workflow that is simply the triggering workflow that calls a child workflow. When you publish your updates, the master workflow will still fire, but fail when trying to call the child workflow - you can then simply resume/retry when the new update is activated.

    In summary - I always do solution import/publishes out of hours where possible to minimise the impact.

    hth


    Scott Durow
    Read my blog: www.develop1.net/public     Follow Me on Twitter
    If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"

    Saturday, March 23, 2013 9:56 PM
    Answerer

All replies

  • No IIS reset happens when a publish occurs.

    Any forms and web resources required by that form would be the ones present when the form was opened.

    I'd be curious if someone had any solid documentation they could provide,

    I could imagine a situation where you made a change and published a different web resource that may be called indirectly from a form/resource and having the content essentially be "out of sync" with what was maybe loaded prior to the publish. 

    Same I imagine would work with any plugins - these aren't called until the related message is generated. So if a form was opened, then a publish of an update plugin was made - I could also envision a mis-match potentially between the form and plugin. 

    So if these items hold true - it would make most sense to publish updates on heavily used systems during off or non-peak hours. 


    Jason Lattimer
    My Blog -  Follow me on Twitter -  LinkedIn

    Saturday, March 23, 2013 6:10 PM
    Moderator
  • I don't know of any documented evidence to back this up, but from my experience this is what I've noticed.

    As you are publishing customizations, users may experience delays in navigating CRM. Very rarely I have seen SQL errors when someone is creating a field or relationship while someone else is publishing, but the changes are never lost and you can simply close the error and save again after the publishing is finished.

    If you are publishing changes to a web resource, for example a JavaScript library, and a user already has a form open which uses that library, the JavaScript won't be updated until they reload the form, so the old script will still be used while still in memory. Only when a web resource is requested again (eg from a ribbon button click, or form refresh) will the new web resource be used.

    Plugins are only called when that message occurs, so for example a plugin running on update of an entity will still fire even if you only just made changes to it while the user was updating a record. The plugin takes a collection of fields that have changed, so it doesn't matter if you've published changes to the form while the user is updating, as the plugin will still just take whichever fields were changed on the current form.

    So basically publishing should be fine, as it's usually quick enough that it's not a problem, but any extensive customizations should be done in a dev environment anyway so you can test and make sure it's correct before throwing it into production. Small hotfixes though, like modifying a JavaScript variable or something should be fine to just update and publish though.

    If you're deploying a solution however, depending on the amount of components these can take up to 20 minutes to deploy, and during that time the system will be offline so it's definitely best to do this after hours.

    Hope that helps

    Paul


    If my response helped you find your answer please show your thanks by taking the time to "Mark As Answer" and "Vote As Helpful".

    Twitter LinkedIn Facebook Blog Magnetism

    Saturday, March 23, 2013 9:09 PM
  • Hi,

    I'll just add a little to Paul and Jason's comments:

    1. When a new plugin is deployed, any existing executing plugins will complete since the old and new are held side-by-side. The same goes for Workflows. This is a really great feature.

    2. If your imported solution contains new attributes/entities - this can often cause SQL errors due to the re-creating of the Filtered Views and updates to the metadata. 

    3. When a solution is published, a new client 'cache key' is created, meaning that on the next load of any pages, the webresources are re-downloaded and cached since the directory path changes.  See http://www.develop1.net/public/post/CRM-Developer-e28098Must-Knowe28099-2-Web-Resource-Caching.aspx

    4. Some published features such as Ribbon Commands require the Async Server to invalidate the server cache, and so can sometimes take longer than other features to appear.

    5. When publishing new workflows, you'll need to deactivate the old before replacing it (unless create an entirely new one). Either way, there is going to be some downtime. To get around this you can create a master workflow that is simply the triggering workflow that calls a child workflow. When you publish your updates, the master workflow will still fire, but fail when trying to call the child workflow - you can then simply resume/retry when the new update is activated.

    In summary - I always do solution import/publishes out of hours where possible to minimise the impact.

    hth


    Scott Durow
    Read my blog: www.develop1.net/public     Follow Me on Twitter
    If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"

    Saturday, March 23, 2013 9:56 PM
    Answerer
  • Thanks Jason, Paul and Scott.

    This was quite an insight. I was trying to look for some documentation to understand the publishing process within CRM but was unable to find any; even on Microsoft TechNet or MSDN.

    This could have been better explained by experienced experts (like you) which made me put up the question here.

    I think I can well conclude it: to publish customization at off-peak hours to minimize impact.

    Thank you again for sharing.


    Regards,
    Gagandeep Singh
    My CRM blog | My SharePoint blog

    Sunday, March 24, 2013 12:36 PM
  • Additional tip: when you import and publish a solution, check the Duplicate Detection rules for any entities included in the Solution, in my experience these may get unpublished by the process.

    Hope this helps.
    Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011
    Blog: Getting IT Right

    Monday, March 25, 2013 11:51 AM