前陣子在某企業分享 DevOps 觀念及 Visual Studio Team Services 使用技巧，不過卻在設定到 持續部署 (CD) 的時候發生錯誤，而且錯誤訊息還非常模糊，完全無法偵錯，直到詢問微軟技術支援中心，才又得知一個相當實用的密技可以分享。
我先說說我的 Release 設定過程：
- 建立 Release definition 定義檔
- 選擇一個現成的範本，我當時選擇 Azure App Service Deployment 範本
- 選擇要發行的建置來源
- 最後只要設定 Azure subscription 與 App Service name 就可以自動發佈到 Azure Web App 上
有了 Visual Studio Team Services 的這些範本，說真的可以節省你相當多的時間，這些範本都是微軟結合 DevOps 過程中的諸多經驗，將常見的自動化流程變成一個一個的選項與欄位，透過簡單的設定就可以完成相當複雜的建置與發行任務。不過，簡單的背後，唯一的缺點就是：「當發生問題的時候，會完全抓不到頭緒，而且因為沒有相關背景知識，很有可能完全不知所措」。你可以看看我當時所看到的錯誤訊息，只有一個 Error: Parse Error 而已，確實相當的無助啊！ >"<
說真的，當下的感覺挺差的，不過還好我們有微軟可以提供技術支援服務 (一般企業也可以向微軟或我們購買技術支援服務)，只要有問題，幾乎都能夠解決，這種隨時有人可以問的感覺，無價！
後來從負責支援我的工程師那邊，得知一個偵錯 Build & Release 執行過程的小技巧，只要在 Build definition 或 Release definition 設定一個環境變數 (Variables) 叫做 system.debug 並將其值設定為 true 即可。
設定好之後，你在執行一次 Build 或 Release 動作，在 Logs 頁籤中，就可以看到相當完整且詳細的執行過程，不僅各式訊息相當仔細，執行過程中所有實際執行過的程式命令與參數，都會一五一十的全部顯示在 Logs 紀錄中，因此這也是一個學習自建 CI/CD 的絕佳管道，如果你想在公司內部架設 Jenkins 或其他 CI/CD 平台，都可以參考這些指令執行的過程，如法炮製完全相同的 CD/CD 流程，這也算是本次事件的一次意外之喜啊！ ^_^
本次問題學習到的經驗
- Azure 資源群組名稱千萬不要用【中文字】
- 建立 Redis 服務一定會失敗
- 使用 VSTS 的 Release 內建的 Azure App Service Deployment 範本會無法成功部署網站
- 只要把資源群組名稱換成英文就好了，不過悲劇的是，資源群組名稱不能改，只能重建 Orz
- 在 Visual Studio Team Services 建立 Build & Release 的時候
- 可以在 Variables 加上 system.debug = true 設定，產生詳細的執行紀錄
相關連結