Release Management 如何查詢 Log 排除錯誤
發生錯誤了怎麼辦
為了台灣，為了軟體開發，聖誕節我們捨棄了大餐一直努力地要排除所有可能的問題，不眠不休地完成讓 Release Management 可以全程自動化佈署 ( 真是太狗血了 XD ) 。當然這中間有遇到很多自已耍笨的蠢問題一直在發生，像是自以為設定沒錯，或是 package 放在錯誤的路徑上等等。這個在上一篇文章中都一一地讓大家盡可能地避免再發生相同的問題，但若是佈署的腳本是要自已刻的話而且又發生了問題那應該要怎麼確認和排除呢？這就讓我們看下去
像這裡出現了建置錯誤，到底是編譯時發生錯誤？還是將建置流程跑到 Release Management 出錯？
開啟「檢視記錄檔」可以看出來，若是建置完成了那麼 package 應該已經會打包好，從最後的錯誤項目來看這裡是因為「發行範本 TailspinReleaseTemplate的部署」未完成而造成的錯誤。這就代表我們連佈署的第一關都還沒有走完就死了，回到 Release Management Client 的項目去查更詳細的原因。
開啟的第一頁馬上就會有剛剛晚上 11:21 出現的部署失敗的項目，這個項目可以點進去看到詳細歷程。
右上角可以看到在 Team Build 的編號 20131225.5 是一致的，至於上面的「放棄」是讓我們決定是否就放棄這次的過版流程，「重新啟動階段」則是可以允許整個的部署流程再重新執行一次，「重試失敗的部署」故明思義就是針對這次有問題的部署步驟再重新跑一次該階段的腳本內容。因為我們發生了錯誤所以先按一下詳細資料先了解原因。
指定 發生錯誤的 Server 和 步驟
從這裡就可以立馬判斷是當初設定時忘了把 Default Web Site 加上去，而導致 IIS 站台在建立時找不到站台的錯誤。
回到上一頁，我們確認一下佈署的流程序列內容
唉呀，真的是因為我們的 SiteName 只有 Web Site 名稱，而沒有加上 Default Web Site
修改好之後我們再點選「重試失敗的部署」，馬上確認我們修改的項目是否正確。另外，這裡修改的序列並不會修改到我們佈署範本，因為當我們佈署的環境臨時發生了硬體或是設定等問題，並只有針對「這一次」的特殊情況而調整的話。就可以直接在這裡修改，每次一佈署的過程中都會有每一次序列流程的歷史記錄非常地方便。
等候「重試失敗的部署」後可以看到我們剛剛的佈署項目已經「完成」了，確認一下網站是否成功佈署上去並可以正常運作。
若是修改的項目要 follow 到所有的範本的話就再到 「發行範本」中進行調整即可，下一次 Release 就會用新的佈署腳本來執行了。
別忘記了 Dev , UAT , Production 都要逐一確認過
