Dynamics CRM中2011：託管解決方案或從DEV到珠三角

Question

部署的更改的動態CRM 2011，微軟建議通過包裝變化管理（或託管）解決方案從開發移動實體的自定義珠三角。非託管是不好的，因爲您無法在需要時刪除實體（刪除解決方案只會刪除容器，解決方案中包含的實體仍然存在）。在培訓期間的大多數實驗示例中，您將自定義系統，然後將自定義實體作爲託管解決方案導出，然後將其導入生產。這種基於解決方案的方法是乾淨的，可以更容易地控制PRD中的內容，將相關實體捆綁在一起，跟蹤依賴關係等，所以我明白了。

有很多次，但是，當你需要轉儲DEV服務器上的組織，並從珠三角恢復（用於解決特定的數據問題或其他原因）。我們通過禁用然後刪除DEV組織，然後要求DBA團隊從生產中恢復CRM數據庫來完成此操作，然後將組織導入DEV服務器。但是，如果我們實施這種基於「託管解決方案」的變更遷移流程，在我們轉儲DEV並從珠三角重新創建它之後，我們不會失去改變實體的能力嗎？這些解決方案都處於只讀模式？如果我們在這些託管解決方案中啓用定製，我們是否能夠向解決方案中添加新實體或從解決方案中刪除實體而不刪除整個解決方案？因爲我認爲託管解決方案被視爲一個單一的代碼單元，所以它要麼刪除全部，要麼全部刪除。有興趣瞭解其他人如何解決此問題。我們已經處理了這個

Answer 1

一種方法是使用我們用它來管理配置的「配置主節點」一個單獨的清潔開發機。該機器不用於任何其他開發或測試工作。 plugsin等開發機器可以從prod重建，但是這臺機器仍然是所有解決方案的主人。不是一個理想的解決方案，但它確實避免了能夠將託管解決方案轉換爲非託管（可能通過某些密碼設施）的「功能差距」

Answer 2

我建議不要在這些類型的dev-to-testing-刺激的情況。

如果你不確定這個嘗試在你的開發環境中刪除實體併發布變更到生產環境。

解決方案是包容性的，這意味着CRM不會刪除解決方案中刪除的字段和實體。

的唯一方法刪除實體是卸載，因此您的解決方案中刪除您的解決方案覆蓋所有實體的生產數據！

雖然理論上解決方案看起來很完美，但它們僅適用於第三方供應商。

通過卸載解決方案可以回滾的beeing的目標是一個夢想。考慮涉及數據轉換的數據模型更新。沒有魔術功能會扭轉這種情況。

這是一個更簡單和可靠的恢復備份。