Dynamics 365-關於Solution的那些事(三)

　　這一篇的內容，是關於Solution的使用建議的，若是你們有什麼實用的建議，歡迎留言討論。

　　一. 版本控制

　　Solution是有版本號的，率性的人可能在新建一個solution的時候，直接賦值1.0，就再也不管了。可是這裏仍是簡單說下MS風格的版本號，通常是用.分隔的四個數字：主版本號.子版本號.編譯版本號.修正版本號。後面兩個版本號可選或者互換位置，前面兩個必須。建議迭代週期，要作好Solution版本號的設計和管理。這方面的好處很少贅述了，畢竟不論是不是開發，都能想得明白。

　　二. 分門別類

　　分類實際上是爲了更好對Solution進行管理。咱們知道CRM有很多類型的Components，而在Solution裏，若是你把全部的Components都放到一個Solution裏，你會發現越到後期，你的Solution就越難維護。那麼是否是我把components從數量上簡單地拆分開就能夠了呢？好比我把不少的workflow，plugin，Entity拆分到多個Solution裏。並不是如此，這裏說的分門別類，通常能夠從這幾個方面考慮：

　　1. component自己的類型

　　2. component涉及的業務：包括業務邏輯，業務部門

　　3. component的依賴關係

　　4. component的數量

　　5. component與項目迭代的關聯

　　如今MS的產品，走的是模塊化的設計理念，那麼這個模塊化，咱們應用到Solution裏，也是同樣適用的。好比你要考慮，哪些Solution能夠規劃成一個「模塊」，若是部署以後，未來客戶不要了，能夠在不影響當前業務的前提下直接刪除（看如今的AppSource裏的Solution產品，都是能夠在不影響環境結構的前提下，實現Solution的導入和刪除的）；哪些Solution是屬於xx部門的，即便之後Solution有更新，也能夠在不會影響其餘部門業務的前提下實現更新；哪些Solution對其它的Solution有依賴，而被依賴的Solution是否是設計的比較Common等等。

　　三. 下載日誌

　　通常狀況下，Solution導入成功或者失敗，最後都會有download log選項。借用這個日誌，咱們能夠準確高效地定位出錯的Component以及可能的緣由。

　　1. 導入失敗

　　不要用記事本打開下載的log文件，那樣你會看到密密麻麻的信息，很不直觀。使用Excel打開log，你會發現全部的component信息，狀態信息，comments信息都已經有條理的列好了，很方便地就能夠找到失敗的component，以及失敗的描述信息，來幫助咱們解決問題。有一點須要注意的是，由於CRM的導入操做就是往數據庫裏修改數據，那麼就會碰到一個讓人很無奈的狀況：即便你的Solution問題再多，CRM也只會導入一次才暴露一個問題，而不是像有統計列表那樣，一次把全部的問題都暴露出來。

　　2. 導入成功　　

　　可能許多人看到CRM顯示Solution導入成功，就直接關閉窗口，以爲log無關緊要了。在這裏，仍是建議你們，即便導入成功了，也把log保存下來。有兩方面的緣由：一方面是即便導入成功了，還可能會有不少的warning信息，有些warning信息甚至會影響後續的操做。好比，你更新一個workflow的Solution，導入雖然成功了，可是你發現爲何workflow activate失敗了呢？若是你查看導入log的warning信息，就可能找到一條提示信息「workflow涉及到user在當前環境沒有......」。另外一方面的緣由，是若是之後有一個環境問題是由於當初的這個Solution，還能夠當作一個處理問題的依據。

　　3. 導入ing

之全部說導入Solution通常都會下載log的選項，是由於還存在非通常的狀況。若是硬件資源不足，或者Solution自己太複雜，可能會出現的狀況，是進度條卡在最後的85%左右，而後就再沒有反應了。這種狀況，能夠經過檢查Solution的版本號，來確認Solution是否導入成功，固然，這個時候，就不會有下載log的操做了。